How to Make Changes to ERP

If your small business can afford a full time IT professional, then making changes to your ERP system is pretty straight forward – you delegate the responsibility to him or her, and make sure it is being responsibly administered. However, if you don’t want – or can’t afford – dedicated IT resources, then you need to establish a process that everyone in your organization understands. The points that need to be addressed in the process are:

Who has the authority to propose, and approve, changes to the ERP system? Proposing and approving should be done by separate individuals. Reciprocating approval authority may be an organizational necessity, but should be avoided if possible. It is a good idea to document the proposal in writing, to arrive at a document as close to a functional spec as possible without being overly burdensome or bureaucratic.

Who will physically execute the approved changes in ERP? This is a much bigger question than just ERP change management, since this intersects squarely with the entire support question – inside, or outside; formal or informal; hosted or owned? If your business is stable, and if you feel like you did a pretty good job with ERP design, then you shouldn’t have a need for more than half dozen changes in a year, and it would be most efficient and most cost effective to hire an ERP consultant or your ERP vendor every six months to make the changes. If yours is a system of constant tinkering and tweaking, then you likely need to get someone internally trained to configure your ERP system. Unless your vendor specifically endorses the methodology, do not plan to make ERP changes by experimental trial and error.

Test your ERP Changes

Trial and error brings us to the final point around making changes to ERP – will changes be tested for effectiveness before turning them loose on the wider organization, and if so, how? ERP Testing is often the path to implementation success, because an integrated ERP system almost always is complicated enough to result in unexpected consequences as a result of change. In large corporations, copies of the production system are maintained strictly for the purposes of testing and verifying, but a small company may only have a production client and a saved backup. If it is possible, make a third copy of the backup, and experiment with your change in that client. If it is not possible, then experiment with the change in the backed up copy of the system. If you make changes directly in the production client without any prior testing, you will eventually get bitten so hard and painfully that you will not want to do it again.

There are many reasons you might want to make changes to ERP - the rules you thought would work for closing out production orders need adjustment; you need to add a new distribution center; you decide that you want to simplify production reporting. It is almost a certainty that experience with your ERP system will lead to changes you wish to make. Have a process to handle those changes.