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.
Featured white papers
ERP Implementation: 9 steps to success
The 11 Proven Steps You Should Know About ERP ImplementationDownload
ERP Implementation Checklist
Over 120 actionable steps to implementing a new ERP successfullyDownload
Manufacturing ERP Implementation Checklist
Over 70 actionable steps to rolling out new manufacturing ERP softwareDownload
Three improvements to expect after retail ERP implementation
The benefits you could see after a successful retail ERP implementation
Risk management and ERP implementation: three tips
Actionable advice for managing risk during an ERP implementation project.
Five requirements management considerations for ERP implementation
Without a strategic approach to requirements management, it's difficult to implement ERP successf...