Ever since returning from SAP SAPPHIRE in June, I wanted to write this blog. Reason being is that I got so excited to see the official announcement of both SAP Simple Finance and the HP Converged System 900 for SAP HANA pretty much in the same keynote. And why the excitement? Because it brings together.
- a tremendous additional business value proposition for Suite on HANA and
- the largest scale-up HANA appliance with up to 12TB of RAM for truly mission-critical deployments like ERP and CRM.
And this, in my humble opinion, changes the cost-benefit ratio for migrating a customer’s SAP ERP system to HANA so drastically that we will see increasing HANA adoption in this key HANA segment. But what makes me so certain about this? Read on to find out!
No more aggravating aggregates
While SAP HANA has improved the traditional SAP Business Suite applications in many areas like Materials Requirements Planning (MRP) and Operational Reporting, improvements so far have been based on targeted optimizations of existing SAP programs for SAP HANA. With Simple Finance, SAP has for the first time fully rewritten and refactored a major Suite component in its entirety and has been able to take full advantage of the power of SAP HANA.
The original trick for Simple Finance was to remove aggregates and the materialized tables they are stored in. Pre-HANA, they were critical to increase system response time – but had the side effect of increasing system management overhead while decreasing business agility. With SAP HANA, these tricks are no longer needed since reporting against the line-item data is extremely responsive and the additional load is highly affordable.
Hasso Plattner explains this nicely in his recent blog, “The Impact of Aggregates,” which make for some interesting reading. He also touches on a situation that I have seen in the past: These oh so rare changes in organizational structures, aka YAR (Yet Another Reorg). So what happens in a traditional SAP Finance system in a management-driven reorganization? Here’s a sampling:
Reorgs entail changes in reporting relationships as well as product ownership. And while reporting relationships are simple lines in PPTs, they have very complex permutations when you look at compensation, bonus pools and cost allocations for overhead. It gets even more complex looking at the product/services side and accounting for cost of goods sold, sales and revenue, all represented in cost centers, profit centers or regular accounts as part of your company ledger and/or sub ledger. For the finance department to manage and report on all these data points in a responsive manner, aggregates for revenue-per-product-line or compensation-per-department, for example, were stored in materialized tables in traditional finance applications before HANA.
Now, when a reorg happens, several or all of these assignments of people, material cost, and revenue to cost/profit centers are changing. To complicate the matter, the active date of the changes may be in the past or future and/or the business would like to simulate the proposed changes before committing to them. And while SAP has built a process called Profit Center Reorganization to facilitate such reorgs, a quick look at this help page describing the necessary steps will give you an appreciation of the limitations and the prohibitive complexity of such a reorg.
Per Hasso Plattner, “the simplification is huge and makes the whole accounting system so much more flexible.” Having been part of re-org projects in the past, I could not agree more.
In short, SAP Simple Finance is a true game-changer for SAP customers and will make the business benefits of HANA highly tangible for business stakeholders. But how about the other two discussion points in every Suite on HANA conversation:
- Sheer size of the ERP database, and
- The mission critical nature of ERP systems requiring 24×7 availability?
It’s true, bigger is better!
Most SAP customers have started with moderate database sizes when first implementing SAP ERP. Over the years, with growing worldwide and functional footprint, acquisitions, plus years of historic data, ERP database sizes have grown into the double digit TB range. At Hewlett-Packard for example, one of the core SAP ERP production systems has the massive volume of 40TB.
While SAP HANA is able to scale-out linearly for analytic use cases and it is well understood how to build large landscapes based on smaller interconnected nodes, SAP does not yet support this for Business Suite on HANA. That means that the only possible and supported way to implement Suite on HANA is by leveraging a single scale-up system configuration. Let’s consider for a minute the HP example with 40TB of uncompressed ERP data. It is obvious, that this single system requires a massive amount of RAM, so let’s do some math: