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

Part 4

More than a decade ago, a survey by ComputerWorld indicated that younger employees would rather quit than deal with the (then )current state of complexity of ERP systems.

More than a decade later, many of those employees, including myself, are no longer young. Still, unfortunately, if you conduct an unbiased, honest survey, you will find that the ERP system complexity is still a significant pain point across age groups.

We may not realize the fact that behind the success of every technology product, no matter how complicated the technology is, is simplicity. In many cases, the product’s complexity may be inevitable. But the output is that it simplifies something. Marginally or significantly. This simplicity is primarily in making something that was considered difficult or easy. The magnitude of “easy” is relative, though, and depends on the current state.

At the core of the complexity of ERP systems is configuring the system during the implementation to capture the current business structures, operating structures, and other nuances. Not only is this initial configuration the source of implementation complexity but also a source of complexity in production. Because the software wants the configuration to happen in a certain way, a lot of customization needs to happen to capture the business nuances the way the software wants to see.

Then, in production, this configuration also acts as a constraint, as we have repeatedly discussed in the previous four parts of the article. A problem with complexity is that once you introduce it into a process or system, the effects keep on percolating. Have you noticed that companies that have invested in large ERP systems are always in “development mode”? They are also working on customizing some aspects of their enterprise system, even decades after implementing it. In one form or another, but consistently.

When these systems originated, there was no better way as well. None. Complexity was inevitable. That complexity was, at that point, something that companies believed they could live with, given the immense benefit of having enterprise-wide visibility into the maze and mayhem of their organization’s business processes. The gist is the benefits, at that point, far outweighed the costs, including the cost of complexity.

That is no longer the case.

The good news is that ERP solution providers are not lagging behind. Technology has just caught up with them and they now just need to leverage it to build the next generation of truly agile ERP systems.

Technology now exists to build enterprise systems that can “flex” at the core. What does this flexing even mean? Let us use an example. If you are familiar with warehouse management modules in ERP systems, you know they come with “preconfigured” business processes. On the one hand, this makes it easy for organizations to implement these products, but on the other hand, you also have to “force-fit” your business processes within this pre-configured world.

_{In my upcoming book “The Homegrown Smart Enterprise“, I am capturing how organizations, if they want, can build a fluid enterprise system, relatively inexpensively. The work is delayed, due to a long drawn relocation process from MA to IL, and the fact that I am typing it on my reMarkable device, where my typing skills are not that good due to lack of a physical keyboard. But Stay Tuned !.}

The most essential ingredient to the recipe of introducing fluidity in ERP systems is to inject simplicity in the core- the capability to configure the business’s current state and subsequent simplicity to modify them. And this can be done by infusing smartness into this process. The fact is that while leveraging AI at the peripheries of the system is beneficial as well, it still does not impact the complexity issue. Making the configuration and subsequent modifications smart, and leveraging the peripheral AI tools to aid in that “smartness” is the answer.

I strongly suspect that ERP solution providers already know this. But there are several bottlenecks. First, there is a massive business with hundreds and thousands of vendors who offer implementation services. These vendors are making money from the complexity. There is nothing wrong with that as well. The hallmark of an astute businessperson is to identify and cash opportunities to make money. For companies struggling with the complexity, these vendors are helpful (provided they select the right ones) as there is no way they could have navigated that complexity by themselves.

However, as technology advances, and now that (I believe) you can build solutions to do the same tasks with much more simplicity and smartness at the core, minimizing this complexity becomes imperative for ERP companies. Once customers realize that there are more accessible (and maybe fun) ways to enterprise systems, most third-party vendors who help their clients implement ERP solutions can direct their attention to another software category. They were never implementing their own product anyway. They will identify some other opportunity. The real impact will be on the ERP solution providers. So, the responsibility to minimize the complexity is on them. Because others actually will benefit from that complexity.

We are focused on the execution layer in this article and not on rewriting the rules of enterprise systems. However, this discussion was imperative since the core cause of complexity, or non-agility at the execution level, originates from the constrained configuration of these systems. However, now that we have touched upon it let us try to understand that, given nothing changes at the core, how can we make execution easier for end-users.

We will focus on scenarios where configurations and master data changes must happen. Now note that based on feedback, solution providers have consistently made changes to upgrade the solution. For example, the system has virtual storage locations where you can move products in case of overflow to execute the transaction. But that is temporary. Those are workarounds built around the core rigidity. If you want to rezone or restructure aspects like the ones below, master data changes must be made.

• Storage types
• Storage sections
• Activity areas
• Activity
• Storage bins
• Staging areas
• Work centers
• Fixed bin assignments

In another example, I leveraged an example of a new route and carrier. In the warehouse management context, examples of additional master data points beyond warehouse layout and activity, are:

• Vendors
• Carriers
• Mode
• Handling unit type
• Packaging material
• Palletization and packaging data
• Routes
• Queues
• Resources

As mentioned earlier, every piece of the master data is both an aid and a constraint. On one hand, these data points try to capture the real-world in the system and ensure data consistency and quality. On the other hand, these data points create rigidity, combined with preconfigured process flows. That means that as processes evolve and flex, the system does not.

In the short-term fix suggested in Part 4 of this article series, we laid the groundwork of the mid-term solution as well. That groundwork, was in terms of identifying the two key pain points:

• End user needs to know what changes
• End user needs to know how to get changes executed

In that solution, the aid provided the information the end user needed to capture process flexes in the system. That was visibility but not true flexibility. In the mid-term solution, we can introduce some level of flexibility. Remember that a truly agile ERP system can not be developed without building agility in the core- by changing the way configuration and master data is captured and updated. Leveraging intelligent automation and GenAI, you can now build such ERP systems. But for now, let us keep the current state of rigidity as a given and build a mid-term solution around that.

What is the primary reason you can’t allow end-users who do not have specific authorizations, to build custom processes or create new data?

Because in the current approach, the configuration and master data define the consistency of the ERP system. You allow employees to build their own custom processes and add their own new master data points, and everything falls apart.

So, how can you address the rigidity aspect without changing the core constraints? The answer is- by leveraging AI. And let us understand the solution by an example. Take a few minutes to review Figure 3. It is a simple doodle but is the initiating point of the mid-term solution. A feature in the menu to create ad-hoc, nonstandard transactions.

Figure 3: “Urgent Transactions” menu

Now in our example, our end-user needs to perform two things urgently because of a volatile supply chain situation. They need to:

• Add new types of handling units
• Change the flow of receipt from production
• Change the flow of staging to consumption

The imperative here is to allow them to execute this transaction painlessly, to align with the process agility, but not allow them to modify the master data directly.

As shown in Figure 3 above, by leveraging a custom menu, the end user can access an interface that shows the current flow in a pictorial format. They can drag and drop to build the modified flow/new process they want the system to capture. They can add master data components, like a new HU, here and then submit the update. Like any normal execution, an embedded A.I algorithm will perform the following:

Create a transaction record, matching it as closely as possible with the existing standard format. This gets included in the existing table to allow the process (and associated flows) to happen in the real world but in the form of mutable rows. If a reporting is being performed, these rows will show separately as “in-process” (like credit card transactions); they may not be part of any calculations and analytics but have still been executed.

In parallel, while the execution was done, allowing things in the real world to keep moving and flexing, the process of validation of this record gets initiated in the system. Concerned admin roles are notified regarding the new transactions under the “urgent” flag, specifically with information on what changed. There will be a specific timeline within which these transactions must be confirmed. Failing the confirmation, these either get dropped or automatically get added to permanent transactions. The person who executed the change will also receive a link later to provide additional details and context around the change.

Recall that our use has also built a temporary, mutable master data record. Like the transaction, this gets appended to master data but can only be used for “urgent transactions” and will remain in a temporary state. Other elements of the process defined above for transactions apply here as well.

This is just a high-level overview. You will have to deal with many aspects to make something like this a reality, but nothing beyond the realms of today’s technology.

Imagine how effortless this whole process becomes for the end user. You can find many reasons why this can not be done. But honest introspection will tell you that it can be implemented within the current constraints of ERP systems. The size of data and computing requirements are examples of challenges. These are cost-related but are not constrained by technology. You must also limit the front-end employees who can submit these urgent transaction requests. These are just examples of issues you will have to fine-tune.

Conclusion

While this series of articles was focused on addressing the system rigidity in volatile scenarios, the fact is that ERP systems are standing at the cusp of a tech revolution era. Due to their market leadership, most of these large ERP solution providers are at a vantage point. However, that vantage point should also allow them to see what is on the horizon. The core of ERP systems needs to evolve to align with the era of flexible and agile technologies.