Why your ERP implementation is out of time and out of budget – Part 2

This article is part of a broader series on common issues with ERP implementations and how to avoid them. Make sure you check out all other parts by following this link!

Part 2. Unstable business processes

Before we dive into the subject of this article, let's start with understanding what an ERP is about. An ERP system is an IT application whose purpose is to improve and facilitate the way business operations are executed and managed, via providing a common platform used by employees in different functional areas of the organisation, thus improving circulation and accuracy of information due to an integrated central database. Therefore, when properly implemented and leveraged correctly, an ERP can actually enhance or at least assist the execution of complex business tasks. What it cannot do, however, is to solve problems that lay outside of the IT dimension, such as unorthodox business practices or unstable business processes.

In fact, a common approach for many companies is to measure the return on investment and benefits of an ERP implementation on parameters such as reduced operating costs, saved labour, or increased operational efficiency, but still they often fail to understand that the system can only be as effective as the underlying business processes it is based upon in the first place. If a business process is unclear, unstable, has a high variance of execution, or it depends more on senior employees' experience and judgement than repeatable and formalised business practices, hardly any IT tool (or any other external influence, for that matter) will make a significant difference in improving it. The ERP in itself will not increase the revenues of the company, it will not handle exceptions during execution, nor it will raise the production throughput. In other words, an ERP is not a miraculous elixir that once operational will fix any and all business shortcomings. Trying to make it happen, namely using the software in the wrong way and forcing it to provide solutions to problems whose root cause lies instead in the business process, generally ends up with a pointless effort and a big waste of time and resources.

So, how is it actually possible for a business process to be unclear or unstable? It's easy: companies change and grow based on a myriad of factors that most of the time are not decided in advance, so "how we do things here" mutates to follow the evolution of the organisation rather than unfolding according to a predetermined plan. Left unchecked, this phenomenon tends to generate a variety of different cases, bringing additional complexity and often increasing inefficiency as well. This includes obsolete procedures, temporary-now-permanent exceptions, or steps with duplicated effort that have never been really addressed.

Then, when the ERP implementation starts and the initial analysis is carried out, key users may struggle to organically describe every use case or even justify why something is done in a certain way. After all, they are immersed in the business reality and rightfully busy to manage the day-to-day operations of the company. They may not have visibility of the whole process, especially when it involves multiple departments or more than one geographical site. This means that, if the initial analysis is not carried out thoroughly and no opportunities for streamlining are spotted, the assumptions on which the system is built may turn out to be fragile foundations.

Ok, let's now have a look at a detailed case to understand how what we just described could happen in practice.

Worst case example: the current production planning process of the company varies widely according to multiple factors and exceptions, including many cases that are handled manually. During the ERP implementation no effort is spent to streamline it, rather the objective becomes to have it all automated in the system. Configuration starts from a basic scenario but more and more parameters are changed in order to include all cases. Exceptions are still not handled, so custom features are created to reach full automation. This requires a prototype with several iterations and, to avoid delays, testing and training are reduced to a minimum. After go-live, end users struggle to make it work, misinterpret some functions, and revert to a more manual process in order to feel extra control over the output. They start blaming the system for the lack of improvement, and efficiency is further reduced by new use cases that trigger the need for even more customisation. Eventually, the production planning module is a beast with high complexity of both setup and usage, showing virtually no realised benefit with respect to the original situation.

How to avoid it: detach the concept of the solution at software architecture level (ERP and integrations) from the solution at business process level, and ensure that the latter is stable and complete by itself. Prior to building the system, set aside some time to analyse and map current and future business processes from start to end, for each relevant functional stream. Assess the robustness of each process and see if some parts can be simplified or even removed, in order to build a system that fulfils actual needs. Reduce the variance of use cases by finding main common points instead of configuring the system to handle a high number of possibilities with low chance of occurring.