When I need to explain the value of S/4HANA to someone in a concise way, I like to use this formula:
The formula gets the point across quickly, but you can spend as much time as you need on each of these 3 elements. The formula demonstrates how improved productivity and new capability is actually achieved by S/4HANA. This is important because every piece of software ever invented claims to improve productivity in some way. And competitors to S/4HANA will undoubtedly say they can improve productivity with their latest product.
But how do they achieve this? What specifically are they doing differently? And can you connect those improvements to a meaningful increase in productivity? With S/4HANA, we aren’t merely saying the technology is better and thus productivity increases. In the same way we couldn’t say a faster car means a quicker commute for you—there is more to a commute than how fast your vehicle can travel.
Productivity increases don’t happen by magic. It must be the result of design. And this 3-part formula, while simple, explains what makes S/4HANA different.
The simpler data model refers to the dramatic changes in data architecture HANA brings to ERP. If you’d like to know more about this, please see the S4in2 video “Why HANA?” as well as the follow-up article.
The improved user experience is all about Fiori. Fiori is simple, role-based, and runs on any device. When Fiori is placed on the simpler data model, the result is that users can go from the high-level view of a dashboard all the way down to base-level detail without having to leave the system or export to a spreadsheet.
And Fiori massively improves productivity in its own right. To see how, I recommend the side-by-side videos comparing Fiori to the classic SAP interface here and here. You can find everything else related to Fiori here.
Productivity really accelerates when the simpler data model is paired with the improved user experience. In the video, the example I give is closing the books. Data reconciliation has always been the big problem with financial close. Every other ERP has to implement workarounds to make reconciliation easier, but here is where our simpler data model really shines.
We no longer need reconciliation “hubs” or other redundant data models because financial data is already in a unified data store. Now add our Fiori interface on top of this, such as Financial Close Cockpit, and our early adopter customers have dramatically shortened financial close. One customer even cut 400 hours per period from their close process.
Is this the kind of productivity your organization wants? I bet the answer is yes. For more information on S/4HANA improvements to finance, see this article.
Another example I like is Inventory Management. The simpler data model on HANA (columnar vs row store) no longer needs row or table locks. This may seem like a small change, but when scaled-out across an entire system, it makes a big improvement in productivity.
A classic problem with inventory management in ERP is Post Goods Issue (PGI), the accounting process that has to happen when goods are moved. PGI often fails in busy environments because batch stock tables are locked. This can result in trucks waiting at the loading dock, racking-up carrier fees.
The past response to PGI locking issues was to have DBAs try to trick the system. Or users simply went around the PGI process or created their own workarounds. None of these options are good. S/4HANA, though, has a simpler data model. We don’t have batch stock tables anymore as inventory went from 26 tables down to 1. So there is nothing to lock, even if HANA did table locks—which it doesn’t!
Now combine this simpler data model with the improved experience of Fiori, and you get truly real-time inventory information with no redundant data needed. You are live on the base transactional detail! My colleague Amr has written an excellent article on how these same concepts revolutionize sourcing and procurement. Again, you can see how simpler design is what drives real productivity.
This is a key point our competitors seem to overlook constantly: we didn’t merely take ERP, wrap it in another data model, and drop it onto an in-memory database. We didn’t merely beautify the UI or port it over to a tablet. We did more. We took that speed and used it to re-architect ERP. Then we paired it with the UI to improve productivity in ways no other system can match.