SAP Business Suite on HANA - Not as sweet as S/4HANA!

[sapsuresh]

How can Suite on HANA be NOT so sweet when close to 2500 productive instances exist all over the world?

I deliberately picked the title to put Suite on HANA in context of where it stands today with the advent of SAP S/4HANA and my previous blogs on the same topic.

I used to communicate the following as the value proposition of SAP Business suite on HANA:

1. Performance optimizations: We delivered 1000+ optimizations just for HANA DB.  Check out my favorite SAP Note 1761546 for details.


2. Fiori apps and smart business cockpits: Leading to better insight for business users and improve productivity.


3. Real-time analytics:  Virtual data model (HANA Live - marketing term) based operational reporting capabilities.

Apart from quantified business benefits as a result of performance optimizations, there were significant technical benefits too.  Such as:

• Database compression:  Some customers reported 5x to 8x reduction of their DB sizes on HANA compared to their legacy DBs.  A side benefit of this high compression was the ability to copy an entire production instance to sandbox or development environments and test new scenarios on the entire production data sets - not just a subset of the production data.


• Consolidation:  An opportunity to consolidated two or more instances on the same HANA appliance - at least in test, sandbox environments.  Benefits were comparable or slightly better than virtualization options but with no performance penalties.


• Custom code mitigation:  Know anyone who uses only standard functionality?  A DB migration to HANA, gave customers the opportunity to evaluate their custom objects (usage, performance, compliance etc.) and either eliminate them or optimize them to take advantage of HANA DB.  An excellent opportunity to clean your house before the big move to S/4HANA.


• A learning opportunity:  DB administrators got to know SAP HANA.  Developers got to know why SAP HANA made sense for applications.

So far so good.  Customers agreed with me on this or at least no one pushed back on any of these propositions.  Fast forward about 4 years to today.  We have SAP S/4HANA in the market with significant uptick in licensed customers and live customers.

Coming back to my controversial title again.  Does it make sense for customers to start a Suite on HANA implementation today given the state of SAP S/4HANA?  Here are some arguments (my personal views) as to why I don't think so.

• SAP S/4HANA 1709 was released to customers on September 15th 2017.  Here is a great start for you to learn more.  This is the third major release of the on premise edition.


• 1709 has reached functional parity with the classic ECC system and I would say is a step or two ahead with new innovations.  Obviously, there are functional differences too (aka - simplification list) for all the right reasons.  Who would accept the same capabilities with no advantages over the previous system?


• Here is how SAP S/4HANA fundamentally differentiates itself from ECC:
  
  
  
  1. User experience:  Fiori launchpad as the single point of entry for business users.
  
  
  2. Embedded analytics:  Tens and thousands of new virtual data models (now delivered as Core Data Service views) to support analytics embedded directly in transactions, new Fiori analytical applications and to support self-service operational reporting needs.
  
  
  3. Simplicity:  Data model simplifications, functional simplifications and landscape simplifications.
  
  
  
  


• If customers are not planning to take advantage of the above, it wouldn't be beneficial at all.

What are the critical effort/cost considerations for S/4HANA implementations?

• Suite on HANA was more or less a DB migration exercise with minor efforts to adopt custom code, implement new Fiori and real-time operational reporting scenarios.


• S/4HANA on the other hand requires
  
  
  
  • large scale adoption of Fiori as the primary user experience layer
  
  
  • embedded analytics for operational reporting (CDS views, built in self-service BI tools like multi-dimensional reporting, analytics path framework among others)
  
  
  • potential business process changes due to new functionality, some simplifications and performance optimizations
  
  
  
  


• ... all of the above leading to change management user training / re-training

SAP S/4HANA, no doubt will yield higher business benefits (compared to Suite on HANA).
Given the effort involved in maximizing its full potential, an unnecessary intermediate move to Suite on HANA doesn't seem to be appealing any longer.  Hence SAP Business Suite on HANA doesn't taste so sweet in current context!

Suresh Ramanathan | suresh.ramanathan@sap.com | Rarely tweets at @sapsuresh

[Former Member]

One comment.
You wrote
•"Database compression: Some customers reported 5x to 8x reduction of their DB sizes on HANA compared to their legacy DBs. A side benefit of this high compression was the ability to copy an entire production instance to sandbox or development environments and test new scenarios on the entire production data sets – not just a subset of the production data".
HANA being an in-Memory database with much larger memory requirements can actually be a hindrance to the whole system copy business.
In the past you could do a full system copy, using relatively cheap storage and a small server/VM to do the actual testing.
However ideally with HANA your target system will have to have the same memory footprint, which is considerably more expensive than disk.
Also compression ratios seem to be coming down regularly. Initially 10:1 compression ratio was promised, then 8:1, then 5:1 with many customers seeing only a 2:1 compression ration.
In once case I have seen a 4:1 expansion ratio (OK this was not Suite on HANA).
Any customer with a reasonably large system, really should consider Data Archiving as part of their migration strategy.
Not an easy sell to the business and not sexy, but a must to keep costs under control.

[sapsuresh]

Thank you for the comment.
I agree that compression possibilities vary from customer to customer. Hence I don’t lead with that as the biggest benefit. You are absolutely right about adopting data lifecycle management best practices including archiving before moving to S/4HANA. Once you are on S/4HANA you can consider data aging for some of the common objects (a/c docs, mat docs, sales and purchase orders and some of the technical docs like - apps logs, work items etc) to optimize memory utilization. Thanks.

[Former Member]

Suresh has nailed it here. Six-sigma perfect. Suresh is a S/4HANA Ninja ....

[glenleslie]

Fenton,

This is another reason SAP has aggressively moved towards cloud deployment options and virtualization support for SAP applications on SAP HANA. These options further assist in deploying on-demand rather than setting up dedicated infrastructure.

We also announced SAP HANA Tailored DataCenter Integration (TDI) Phase 5 at SAP Teched 2017 in September which further helps to right-size HANA installations for TCO considerations.