The right approach to S/4HANA - Blog Post #6: Are non-Intelligent Enterprises dumb?*

*sorry for this clickbait headline, but great to have your attention.

The “Intelligent Enterprise” is the strongest value proposition in the world of enterprise software. It replaces traditional insufficient value models (“this process gets 20% better, that process 22% …”) with the focus on a higher enterprise value release by enabling completely new processes and business models.

In the last Blog Post I went down to the basics of this value proposition by describing not only the cure that is the “Intelligent Enterprise” but also the disease, the outside-in inducted pressure companies are experiencing that forces them to digitize their processes to be able to cope with the challenges of the 21st century.

But still, astute customer executives may sometimes provoke you by implying that companies that are not yet on the “intelligent enterprise” path are supposed to be dumb?

But still, astute customer executives may sometimes provoke you by implying that companies that are not yet on the “intelligent enterprise” path are supposed to be dumb? Well, if you find yourself in such a situation you have basically two options: Hide away and revert back to an archaic features and functions mindset that will send you and your customers again into a vortex of never ending value discussions (discussions the intelligent enterprise premise helps to avoid), or you take on this intellectual challenge and explain “cure and disease” (See Blog Release #5) and add another viewpoint into your explanation which is as impactful as trivial: The insufficiencies of traditional enterprise software which are no longer bearable in context of the disturbances of industries in disruption and political and economic uncertainties, which is today’s topic.

It is about identifying the “handbrake”, the inadequacy of traditional ERPs that were once huge helpers but have become complex and inflexible because of vastly changed external circumstances companies are experiencing in accelerating fashion. Things like the not merely growing but exploding data volume enterprises have to cope with (remember: 90% of worlds data are less than two years old).

And don’t believe it is getting easier: In the end of 2020 it is expected that 212 billion “things” will be connected in a global IoT trend, which is only the beginning. And those 212 billion “things” (Telco devices, machines, cars, etc.) will generate more and more data and add growth rate to the already existing data explosion.

And you want to include social media data into your business to learn more about your customers wishes and desires? Well, then let’s take a look into your existing legacy system: When you talk to board members and CIO’s you can condense the issues of running “Yesterday’s ERPs” into two mutually dependent problem complexes:

-         “Scattered information” and

-         “Batch orientation”

“Scattered information”:

You can call this the basic issue. The architecture of most common ERP systems today’s companies use date back to the late 1980s/ early 1990s, a time we all were wearing mullets and thought Roxette was cool!

As revolutionary those ERP systems were back then, the underlying data models were not that sophisticated to cope with the uprising “special wishes” the lines of business organizations started to have concerning their specific and individual demands. Production planners needed better system support as well as sellers, marketing people and so on. In consequence, the system providers built specialized solutions to cope with those specialized LoB demands, that in turn had their own specialized data model.

But this meant each of these systems had to run on its own machine with its own, separate data storage, based on the aforementioned specialized data model. Not a big issue at that time though, the advantages of these specialized LoB solutions, that accompanied the core ERP systems by far outclassed the disadvantages of those dispersed architectures, that started to exist because of that specialization. But still, the backside that gained momentum over time was that those separate data storages create autonomous and alternate versions of information.

Example: When a planner wants to solve a problem (e.g. material shortage) within a LoB solution like the APO by rescheduling an order, he does it in the version of that order that is stored within the APO database. The order has now a new due date that the customer agent, who works with a CRM system that has a completely different database with its “own version” of the order information, is not aware of since he only looks at his “version of the truth”. He is informed at that moment when after a certain time (this can be days) the value change of that order reaches the data storage of the CRM system.

Or in other words: Dispersed architectures consisting of a leading ERP and satellite applications for specialized processes like Planning, SCM etc. result in redundant data with different ages and different values. What does this mean? Any company running these systems has no transparence about the actual logistic situation and no possibility to react to problems quickly and in a suitable way.

Comparison: Tables in a traditional ERP database versus tables in S/4HANA

But that does not mean this only happens outside of your legacy ERP. You can find lots of aggregate and index tables WITHIN your traditional system whose only purpose is to prepare information and data for faster reading because of performance issues caused by severe data growth. But they cause a new problem on the other side since they also mean additional versions of information again.

Want to know how this issue affects your MRP? It has to go into 42 different database tables for each (!) planning file entry it has to calculate. Sounds slow? It is slow.  

Or like the CIO of a DAX company says: ?We cannot react to changes in customer demand in time, because our traditional ERP neither gives us the transparence how we can handle a new situation, nor does it give us the agility to react in time and put insight into action!“

“Batch orientation”:

This second big issue is a direct consequence of the first. When you have a dispersed architecture consisting of one (or several) ERP and LoB satellite applications like planning, warehouse management, transportation management and customer relationship management solutions running with their own data models and thus with their own data storages which mean each system has its own separate version of a information / data, you need batch runs to bring everything together again.

These batch runs are for example the CIF interface between ERP and the APO or (and this is quite important) can happen within an instance like the rough cut capacity planning or the material requirements planning run.

Or in other words: When ever you want to see where you are, you need to wait till these batch runs (that run each night) have sorted out which version of the truth is the correct and most recent one. Even more: When you are working with data (orders, master data etc.) you see the results of your work e.g. if your solution to a problem was successful or not the next day – not immediately.

And this issue gets even bigger, just take the big data growth rate into account. Those batch runs are getting longer and longer, some companies are forced to reduce their MRP runs to once a week on a weekend and the outlook sees those monoliths of the 90s at even bigger pressure.

In the end, the separation between user and reality is getting bigger and bigger and putting insight into action gets harder and harder. Or in the words of our DAX CIO: ?Weirdly, concerning logistic process improvement, we have focused our energy in the last 10 years mainly on improving the runtime of our MRP instead of innovation and your strengths. And data growth gets bigger and bigger. “

Right, you will have to put even more effort into keeping the lights on like optimizing the MRP so it fits into your timeframe instead of putting your energy into the things that matter much more: Getting your enterprise onto a new level of business value. Not a promising outlook and one more reason to digitize your core with SAP S/4HANA because it solves this data model issue with its unified data model, that enables not only the elimination of index and aggregate tables of your ERP but also makes co-deployment of former satellites possible. The result? Real time processing and unlimited flexibility.

To come back to the beginning of this article, what should you use as answer to the question “Are non-intelligent enterprises dumb?”: No, but they are far behind their possibilities. Using traditional ERP systems that have their roots in the late 1980s/early 1990s in the 21st century is like the old saying of “bringing a knife to a gun-fight”.

Using traditional ERP systems that have their roots in the late 1980s/early 1990s in the 21st century is like the old saying of “bringing a knife to a gun-fight”.

Using ERP software, that was developed at a time where the least of us were using emails or mobile phones, today where modern startups use cloud software disrupt entire industries is hopeless. So switching to modern enterprise solutions like S/4HANA and digitize your core is not a matter of improving the aforementioned percentages in certain processes. It is about survival.

Time to move on S/4HANA now!