S/4HANA momentum continues with 4 major releases and over 1,000 live customers. Still, one of the top questions I get is, “Why doesn’t S/4HANA run on Oracle (or any other database besides HANA)?” This is a natural question, especially since SAP partnered with database vendors for our products prior to S/4HANA. Sometimes there is even speculation of an “S/4Oracle.” It’s not going to happen. Continue reading to learn what makes S/4HANA unique, and why ERP running on legacy database systems are now obsolete with S/4HANA and S/4HANA Cloud.
Why HANA?
Several years ago, SAP introduced the motto “Run Simple.” This is a nice sentiment, but how do we make it real? We start with the data model used to run ERP. The data model had to be simplified—this is the foundation of every innovation since.
Some concrete examples:
* Inventory Management went from 26 tables in ECC 6 on legacy database to 1 table on HANA.
* In Finance, the Universal Journal (1 table) eliminates the painful process of FI-CO reconciliation (many tables).
* Extended Warehouse Management is back in core ERP and no longer needs its own system since the complex model required by legacy databases is gone. The same is true for Transportation Management, Advanced Available to Promise, and Advanced Variant Configuration, among others.
These aren’t dreams—these are innovations and productivity gains our customers are getting now. Imagine liberating your finance department from unproductive spreadsheet rodeos like reconciliation. Imagine providing your colleagues in supply chain MRP runs whenever they want, not just once per day. You can do this all while simplifying the IT landscape. With a simpler data model, your IT department is ready for anything, and your business is equipped with new, real-time capabilities.
These gains are simply not possible running on legacy database systems. We had to take the dramatic step of re-designing for an in-memory, columnar database. Obviously, we chose HANA for that. It isn’t good enough to take the 26 tables for Inventory Management and run them in-memory on, say, Oracle 12c. Simply running in-memory isn’t enough—we needed to leverage in-memory to redesign for a single data model. If you have a couple minutes, take a look at my video explanations here, here, and here. If you have more time, get a deep dive here.
This is also a recognition that with the move to a pure in-memory architecture, the two layers of database and application are merging. In the past, we depended on a separate database layer to organize data for transactions and analytics. Now the application can access the data with plenty of speed in-memory and not need to have it organized in advance. Trying to make this work with every database vendor’s different architecture would have limited the innovation and delayed the benefits for our customers.
This is why we won’t have an “S/4AnyDB.” We can’t move our customers back into the complex data models of into the past. We partner with database vendors for ECC 6 which we continue to support until 2025. This explains why you might see agreements with them: it’s to support the past, not enable the future.
Is It Working?
The real-world results are proving this was the correct strategy. The impact of a simpler data model is amazing. Business processes are transformed everywhere (see illustrations here). The best proof, however, is in the unprecedented adoption numbers for S/4HANA, the fastest-growing product in SAP’s 4-decade history. In a bit over 2 years, more than 6,300 customers have purchased it, and over 1,000 of them are already live (check out their stories). The transformation from traditional DB to the new HANA architecture has not been a limiting factor.
If you are running ECC 6, try our Business Scenario Recommendations tool as well as Readiness Check. With these free, personalized tools, you can find out exactly what the simpler data model of S/4HANA will mean for you. http://bit.ly/2gHQxwy #SAP #SAPCloud #AI