This article is a part of a series of five articles that discuss the topic of building agility in ERP systems. The previous parts can be accessed here:

Part 1

Part 2

Most software solutions have always been badly designed. For decades.

To be fair, the reason primarily, for many decades, was that the technology to make them what they ideally needed to be, was either not there or it was not realistic to embed those technologies into the solutions. That is no longer the case.

The postulate here is simple. If you want to build a flexible and agile supply chain, your systems need to follow suit.

Let us start by revisiting Figure 2 from the second part of this article. While there needs to be some fluidity in the planning layer, the lack of fluidity in the execution layer hampers solutions from becoming truly agile.

Figure 2: The fluid execution layer

Enterprise software solutions are still rigid like they were almost half a century ago. While this rigidity at the bottom two layers of the stack, shown in Figure 2, may be acceptable, the rigidity in the top layer is detrimental. I have quoted a few examples in the last two parts of this article (Part 1 and Part 2 can be read here). But what is the alternative?

This is the differentiating layer if you are looking at this from a solution provider’s perspective. Your “record” layer is merely a data repository behind all the jazz of capturing real-time transactions. While visibility is a benefit, the gist is that this can be replicated using open-source solutions within weeks. In fact, you can build this layer more intuitively, using open-source tools and far less expensive solutions, within weeks.

Then comes the planning layer. Most planning solutions today are almost identical, sans the features and UX. In fact, significant approaches used in these tools are based on classic optimization methods. Suppose they are embedded within solutions themselves. In that case, the enterprise’s only differentiating aspect is that it can seamlessly integrate and tap the data captured in the record layer. This is the “rat race” layer, where a new product enters the race every time you blink. Differentiating from the current approaches is very challenging.

The execution layer is the one that is the most critical not only from the angle of the fluidity requirement but also from the viewpoint that we often ignore in enterprise systems- end-user “lovability.” When we talk about agility in the supply chain, we mean processes that can flex. And the associated solutions need to flex as well. But whether these systems flex or not, your people have to work with these systems to execute the modified or alternate processes.

At the core of building fluidity in the execution layer is the iterative design approach. The execution layer in these products needs to be transformed into a revolving and circularly revisiting design practice. And there is no method better than “design-thinking” to make that happen. But then, you may argue that this is not realistic. Large enterprise software companies can’t leverage an iterative process to keep this layer fluid, considering how massive their systems are. The significant aspect of what we will discuss is that they do not need to.

A problem with our approach to trends in technology is that though we embrace these buzzwords, we do so primarily for marketing and hype creation. For example, self-service app development is a capability that I believe can completely change solution building in today’s world. But we have not even scratched the surface with this capability. At the core of what will help enterprise solution providers build the execution layer fluid will be citizen developers.

We will start exploring the architecture and process of this approach in the fourth part of this article series, to be published on 11/9/2023. In the fifth and final part, we will conclude with an approach that can be the start of the next step of evolution on ERP systems.