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

In 2019, I wrote an article on why CPG companies must become technology companies. The gist of the article was that organizations need to realize that they are essentially leveraging technology as a core enabler to execute operations. Hence, siloed thinking of technology will not help build the capabilities they need for the digital age. The triad of people, processes, and technology must be strategized together. Hence, companies need to realize they are as much a tech company as a business process company. While the article was focused on CPG, it is true for most industries.

But executing this is easier said than done. Because technology needs to be synced with your processes and people as well. All these elements need to work in unison for an organization to become an actual digital enterprise.

Let us simplify the layers of enterprise systems organizations deploy. As shown in Figure 1, at the core is a transaction module that captures business transactions as they happen. Then, we have planning modules. These modules leverage the transactional data to find better ways of executing business processes.

Figure 1: Layers of enterprise systems

Let us imagine a hypothetical scenario. You have a finished goods warehouse suddenly overflowing with a particular product. If you are familiar with configuring warehouses in the enterprise systems warehouse management module, you have defined zones and associated products. This sudden overflow now requires you to be “flexible” with your putaway to accommodate the product while minimizing the impact on your operations.

What happens in real life is that when such scenarios happen, warehouse managers face an additional challenge. On the one hand, they need to optimize how to accommodate this influx within their operations; on the other hand, they also need to figure out how they record these “accommodated” transactions in the system. Essentially, movements must be recorded in the system (which is fair), but gaming these configurations to record movements becomes a task since they are now not as per the configuration. The system is not fluxing with the volatility. It is adding to the volatility.

So, how can such a system help with agility?

We like to use examples of events like COVID-19 to illustrate how digital tools can help with agility. So, let us use that example as well. We will use a less severe example that is not akin to a black swan event. The idea is to illustrate that even in these less severe scenarios, the tools are not providing the level of agility we need.

The Suez Canal is blocked, so your ocean shipping lane is defunct. You have a so-called “Scenario” analysis module in the planning layer that can help you identify alternate routes. Does that help with agility? Let us say it does a little for now since it tells you what can be done. It does nothing to help make what needs to be done more accessible, but it somehow helps. But then the challenge of execution part again comes into play. And the systems, rather than helping ease the execution, create an additional task. As you will see or have already visualized, the constraint will be to capture the alternate arrangements in the system so that the movement is captured. The execution layer does nothing to help the transition to alternate options easier. It actually creates additional tasks.

So where is the agility?

What we need is actually an execution layer that flexes with the process. As you can see in the examples above, the process needed to be changed. This is a fundamental requirement of building agile supply chains. You need to have processes that can flex with the requirement. But then the systems also need to evolve. After all, it is the triad of people, processes, and technology that all need to come together to create a truly agile and flexible supply chain.

This is where the fluid and iterative execution layer of the hierarchy of the system comes into play, as shown in Figure 2.

Figure 2: The fluid layer

In the third part, to be published on 11/8, we will delve deeper into the need for an iterative software approach to execution systems. In the fourth part, we will start discussing how to build fluidity using technologies available today and conclude that in the fifth and final part.