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

Part 3

At the core of the configuration of an ERP system is the master data. So, if a sales order is being created by an end user, this transaction will have to leverage the master data that already exists (like supplier ID). The master data will then be leveraged to populate information like name, address, and address. As you can assume, this ensures consistency and, ideally, should make the task of the end user performing the transaction easier. They do not have to enter 100 different columns of information. Execution should hence become easier. It is, in most cases.

But we are talking about resiliency and agility here. Which primarily means handling scenarios that are out of the ordinary. This is where the challenges originate. This is where the rigidity of pre-configurations becomes a challenge. This is where the execution layer becomes a challenge when sh*t hits the fan.

Let us first identify the two primary bottlenecks.

Key bottlenecks that hamper agility

The first and most important is that we don’t want everyone to make changes to the master data. Allowing that defeats the entire purpose of having an ERP system. Let us revisit the Suez Canal example from part II of the article. The scenario planning module suggests an alternative route. The challenge is that no carrier on that route exists in the master data. And adding one is not something that end users are authorized to do. And you know that you will now be using this carrier for a while. So you raise a ticket and wait for approvals and authorizations, and then eventually, someone in IT makes updates. The scenario above is simplified, but the fact is that multiple changes may be required in the master data.

In a scenario where every minute counts so that a shutdown of the manufacturing line can be avoided, adding that new supplier to the master data becomes one additional challenge vs helping resolve the issue.

The second one is that even if the first bottleneck identified above can be addressed, there is no proactive agility at the execution layer. For example, there is no tight link between a mitigation step suggested by a planning module and execution. If they decide to leverage insights from planning and analytics modules, end users will need to figure out how to make that work in the execution layer. This defeats the entire premise of ERPs, which was built on connecting the information across the enterprise.

There are two approaches to this.

• The first one is a short-term modification that can be made to the software to help it address the bottlenecks identified above.
• The second is an approach that will take effort, hence is a mid-term approach, but will help ERP providers make the execution layer genuinely fluid.

The short-term workflow modification approach

So, let us now try to understand how these two bottlenecks can be eliminated using the short-term workflow modification approach. For this discussion, we will not explore the possibilities of enhancements in layers like record and plan. We will instead focus on leveraging an intelligent workflow approach to address the two bottlenecks in the design.

A workflow in an ERP context controls the flow of information within the ERP system and may create additional tasks for seeking additional information or approval. Every execution transaction is, hence, part of some workflow. The very nature of interconnectivity in ERP systems, which makes it so powerful, is powered by these workflows since an execution in one area (like supply chain) also impacts other areas (like finance).

One challenge in many ERP systems is that their analytics and planning systems have been bolted on the original ERP. They seamlessly integrate with information in the core ERP for sure. However, they are not seamless enough to be “one entity” with the ERP system. Addressing a part of this is the first step of this short-term fix.

It should not be difficult for the planning module to identify the workflows impacted by the alternative scenarios suggested. In our simple example of choosing an alternative shipping route and associated supplier, the planning module should be able to identify and flag critical pieces of information like:

• The workflows impacted due to the disruption (workflows which will have to be modified)
• Details of each workflow, like approvers, master data change admins
• Critical flags (No supplier exists for a specific shipping lane)
• Workflow restrictions for the role accessing the scenarios

The list above is representational but is the foundation for this approach. This does not require any “AI”. It is a simple reconciliation exercise that the planning module should be able to identify since it was developed by the ERP provider. Hence, there is seamless and uninhibited access to information.

The end user now has all this information available that they need to understand what are the impediments to executing the alternative. While the system is not agile, it is starting to address the agility issue by helping with the transition. The next stage is enhancing the workflows to make execution less painful. As a reminder, this short-term approach is not the fluid approach we want to focus on.

The end-user has all the information shared with each scenario the planning system suggests. But this, while a helpful improvement from the status quo, still does not address the fact that the end user now has to address all the issues and hoops identified. But let us now envision what an improved solution may look like. Each suggested scenario has an “Execute/Accept Scenario” button. After various discussions and deliberations, suppose the end-user decides that the scenario is what they want to leverage (or a version of it). In that case, the user can start a workflow by clicking “Execute/Accept Scenario”.

That click triggers a workflow that sets things in motion for the end user. Tasks include notifying the person who approves new carriers and requesting a new setup. It also triggers emails for any approvals that may be required. While this still needs the end-user to coordinate everything, they are not left hanging to decide what needs to be done from a system perspective and get stuck because they can not execute the change in the system. While still not true agility, this level of agility flexes when there is a process change. You can see how beautifully the three components of people, process, and technology flex, to varying levels of degree, in this scenario. That is what true agility is.

In the fifth and final part of this article, to be published on 11/10, we will conclude with a discussion of the mid-term approach, an approach that builds on this short-term approach and can be the start of the next step of the evolution of ERP systems.