Who should “get” the HANA message? The forgotten ones.
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.
Thanks Axel for your commment.
We are very aligned here.
The suggested BLOG is also a confirmation that we are not alone thinking this way.
I however think that we are pioneering it. Lots of people still talk about raw speed...
Also, another important point is reach. This will have to be done with the help of the ecosystem. It is not realistic that SAP will be able to deliver this message alone.
Thanks again
Hi Leonardo,
thanks for valuble information putting together.
Can we have business suite on hana along with BW and BPC on same hana database ?
as per note 1826100 - Multiple applications SAP Business Suite powered by SAP
HANA ,it is not possibel to club ,only whitelist applications can share same hana db and not bw and bpc in that list .
,but some sap documents says,we can have BW and Business suite on same hana data base(25,33 page)
"4011 Leverage SAP HANA Analytics Foundation to Bring Operational Reporting to the Next Level Using SAPs Suite Content".
so i am confused should we have different hana data bases or one we can use share for both bw and business suite and use same phisical tables data and aviod extraction at lease for some extent.
Hi Jyothi,
Technically the HANA DB can be "partitioned" to serve as DB to multiple applications. Of course there is a question of compatibility, therefore the note you mentioned is very relevant.
However, there is a question about sizing and more importantly architecture. Unless you may be talking about a demo system, why would do that?
Now, a precision. Running ERP on HANA and BW on HANA makes sense. BW is a datawarehouse. It allows historical analysis and also can model and report external data (or from multiple SAP systems). What you refer to as the Analytics Foundation, now called HANA LIVE, is something else. It is a modelization of ERP data that allow super fast reporting. This is for operational reporting.
Hope this helps
Thanks Leonardo,
We are planning for production system and not for demo system and Analytics Foundation i am referring is HANA LIVE.
1.if technically and functionally possible to share same hana db with ecc
,bw,bpc,we can save time of data loads and read data from same db and from
different schema.
hana db or bw hana db ,which is best place to have hana live.
reporting on top of BW with boboj without data replicating from business suite
on hana.
please provide your inputs.
Leonardo, I've just been re-reading your blog and could not agree more. Sadly, it's been over a year already but not much has changed. Maybe I'm missing something but the functional specialists don't seem to be getting engaged enough in the HANA conversations. I believe it is still very much perceived as a purely "technical change", which, as you are correctly pointing out here and in the other blog, it really isn't.
Thanks for your comment Jelena.
Agreed.
This touches a more complex underlying problem: Justifying HANA. Who should do it? and How?
It is a business case and therefore I believe Functional analysts have a big role to play here but honeslty ,we just see little traction...
I believe this will need to come "Canned" from up above... meaning, when SAP comes up with its new ERP solution (whenever that happens) that is a convergence of Business SUite tools in one application running optimized for HANA, then WOW, everyone will "get the message" and jump on board.
Lets see...