If you remember taking pictures and sending them to friends and family as recently as the 1980s and 1990s, you’ll recall that it was a complicated process. You recorded pictures on film which had to be processed with chemicals. Then pictures were printed on paper and sent via the postal service, itself a complicated web involving tens of thousands of people and vehicles. Eventually, this process could be sped up by using one hour photo processing and overnight delivery. You could get a picture to someone in as little as a day. While this improved speed was nice, at the core, this process was still as complicated as it ever was.
Then the internet changed everything. Now, your “camera” is really a network node that can transmit a photo to anyone in seconds. But it is not merely faster, the “architecture” has been reduced dramatically. This simplified model is really what drives the photo and image applications we have today. The simplified architecture, not simply improved speed, is responsible for the explosion of creativity we have now.
What this analogy illustrates is that speed alone is not sufficient. If you aren’t removing layers from the architecture, you aren’t simplifying anything or unleashing creativity on the problems we have today.
In a sense, all other ERP solutions today, including running ECC 6 on HANA, are like the old way of sharing photos. Yes, they can be made faster in some areas. But only S/4HANA takes advantage of the speed to dramatically simplify the architecture.
Let’s take a look at this now applied to Inventory Management in ERP…

You can only get this simplification and the resulting new capabilities in SAP S/4HANA. Simply running your existing ERP in-memory, even if it is the latest SAP ECC 6, is not enough. Taking what you have today and running it in memory (Oracle 12c or any other in-memory DB) does not result in any benefit other than some improvement in query times. To get a benefit as big as eliminating reconciliation and locking, we must re-architect the system, and that is what sets S/4HANA apart.  
No other ERP solution is re-architected to take advantage of an in-memory database. This is what we mean when we say “simpler data model.”

First, a finance example. Every organization has to close the books, and this has been true since double-entry bookkeeping began. Closing has always required the finance department to reconcile two different types of financial data: Finance (FI) and Controlling (CO). This reconciliation has been one of the biggest hassles and wastes of time and resources. What if we could simplify the underlying data model so that this FI-CO reconciliation was no longer needed? We can do this with the HANA in-memory database (more on that later). Then what if we put a simple, role-based UX on top of this simplified data model that allowed finance personnel to drill-down to any level of detail necessary without exporting to spreadsheets? With the SAP Fiori interface, we can do this. Combining that simpler data model with the improved UX gives us a new capability: soft close anytime. This gives finance the opportunity to run a “close” any time they want, to see what will happen and catch errors early. It turns the closing process from an insufferable chore that drains hundreds of hours per fiscal period in to something that happens in a moment. What CFO would not want that? And what CIO would not want to bring in this capability?    
The complexity found in decision making, process execution, and IT architecture has a high cost. The illustration on this slide shows specific examples of complexity in finance, and what results.  
Decision making: Finance has to wait for experts (usually in IT) to gather and prepare data to analyze. By the time this is done, the problems finance is trying to discover and diagnose have often become unmanageable.  
Process execution: Today’s batch-oriented processes, like period-end close, not only suffer from the inherent latency of a batch operation, they also rely on manual reconciliation between finance and controlling systems. The result is that there is no time left in a period to check for errors or even simulate what would happen under different conditions, such as an acquisition, divestiture, or reorganization.  
IT architecture: Because there has been little structural change in finance systems, IT must spend time to create interfaces and reporting layers to help bend the business into the predefined structure demanded by the system. As a result, businesses cannot really optimize the way they work. If they do reorganize, this creates even more of a burden on one-off interfaces or reporting structures to handle the differences.  
All this complexity is not trivial. It eats into more than 10% of profits.

Then what if we put a simple, role-based UX on top of this simplified data model that allowed inventory KPIs to be refreshed instantly? Combining that simpler data model with the improved UX gives us a new capability: reducing PGI times. This, in turn, reduces carrier fees as trucks are no longer sitting around idle waiting for PGI. What COO would not want that? And what CIO would not want to bring in this capability?  
The example on this slide is from a real customer, but it is not unique. PGI locking issues are notorious in legacy ERP systems, and work-arounds are common. This example shows how a simpler data model, not merely a faster one, can impact a business process.