Lessons from Process Simulation in ERP
The keys to successful ERP implementation are not really a secret anymore. You can look them up on the Internet from any number of sites that claim to understand these factors. From my perspective, I’ve always believed ERP implementation is very simple if you follow one basic line of logic. The entity the ERP system must service requires a predictable, reproducible process that it will use to perform business operations. Everyone within the entity must know what to do and how to interact with the system.
In all likelihood, the ERP system you will be working with also has a process that it uses to process the data you provide. And, frequently, there are differences in the way the process is conducted. This is typical and, if discovered in advance, can often be accommodated. Unfortunately, what often occurs is that the process gap is not discovered until sometime after the system is operational causing painful delays and workarounds. Closing process gaps between the currently employed business processes of the client and the ERP system processes is a normal part of implementation.
But timing everything and finding these gaps in advance is critical to ensuring your system start up is smooth. Finding gaps is simply a matter rooted in reality. The process must be executed at the ground floor level within the ERP system to discover where the current business process conflicts with the ERP process. Getting the right people involved is critical. You need to ensure that those who execute the process get a proper opportunity to see what the ERP system will do and, if possible, get an opportunity to execute their process in a test environment.
First of all, this provides some of the training that is needed. And secondly, it is the best way to get them to ask questions and create a dialogue between the implementation team and the system users. It is my recommended way to expose gaps. And you should also document them thoroughly as they are exposed. Once you know where the gaps exist you can determine what actions will be appropriate for each one.
Normally, there will be two choices. The entity will adapt their current process to a process that the ERP system supports, or the software will be adapted to the needs of the entity. Sometimes there are compromises on both sides. The objective is to take the path that serves the entity best in the long term. Often, it is simple for the entity to adapt to the software process and take advantage of the existing automation. But this isn’t always the case. Often, an entity will have specific processes that give them competitive advantages, that they need to function in a particular way within the system.
Many ERP systems aren’t adaptable to special needs. Ensure the system you buy has this capability if you require it. I also recommend that you don’t rush the simulation. Give yourself enough time to do it right within your timeline. Extending your timeline to include simulation, if you hadn’t considered it, is the best decision you could make. I’ve seen simulations in complex medium-sized companies take as much as two weeks to do it right. And sure, it can be expensive to do a long, detailed business process simulation. But the cost of doing it poorly, doing it in a rush, or not doing it at all can be staggering. At best, it will be an aggravation that will cost you money. At worst, your ERP could fail you in a critical area at a critical time.
So, no matter how well you think you understand the process you should still simulate it in an ERP pilot prior to going live. Find the gaps, close them, and then you know you’ve got a solid foundation upon which to train people.
Mike says “You shouldn’t wait to simulate!”