ERP Myths: Understanding ERP Software

A common thread around ERP myths is that people bring their PC software paradigms to an ERP implementation. For instance, if you are known locally as pretty much of an expert on Excel, and an expert on Power Point, isn’t it reasonable for you to set as a goal to be an expert on ERP? The answer is “no” - understanding ERP in its entirety is tough. It is reasonable for you to become an expert on one ERP module, but extremely difficult to become an expert on all –or even many – modules. There will be exceptions to this generality: a simple ERP system in a small company implemented and supported by one IT professional will likely be pretty much fully understood by that IT person. But if the ERP system is reasonably complex, with multiple integrated modules, and the ERP implementation team is comprised of cross functional subject matter experts, understanding ERP across the board will be difficult.

Barriers to Understanding

The reasons for this are more evident in retrospect than they are proactively intuitive - this fact is fuel for many an ERP myth. The first problem is that ERP module blueprinting sessions are typically held concurrently, so that it is impossible to participate in every design discussion for every module. Without understanding the design decision details and the tradeoffs and compromises made, it is impossible to perform the appropriate configuration. Without understanding the configuration,understanding how the ERP module is supposed to operate, and how it affects other functions is almost impossible.

The second barrier is that once the module is running, either in integration testing or after ERP go-live, all of your time and attention is spent testing, operating, tuning, and troubleshooting that module. In many cases, segregation of duties requirements may prohibit you from even having physical access to other modules and transactions. Over time, you become an expert on that module simply by virtue of the fact that you have spent all of your time working on that module.

The last barrier to having a broad and deep knowledge of ERP is that all of your value lies in what you know about your module, and there is no obvious value to the organization to invest in you becoming an expert on another module. In the private sector, an ERP implementation consultant, or contract support will be hired for their current expertise, not their ability to learn something new.

The point of all this is, ERP is normally too big for any one person to absorb all of its capabilities and functionality (even experts are continually learning new things about what capabilities a module has). This can become an issue with ERP change management and the people who have traditionally been the thought leaders in your organization. They may resist losing their status as business generalists, de facto IT experts, and the ability to design new computer systems on a whiteboard, and translate that resistance into constant dissatisfaction with the design or implementation.

Prepare your informal leaders accordingly. Dispel the ERP myths.