- Let employees first get a feel for the software before making changes.
- Only customize in areas where you derive a strong competitive advantage.
- Adhere to the software’s guidelines for customization to ensure smooth upgrades.
I couldn’t agree with this article more. The most “challenging” implementations seem to be the ones where the stock system is customized from the very beginning of the implementation. The users don’t get to use the system in its unmodified state, and are handicapped in their understanding of how the system works. When things go wrong during processing, the user then has no idea how the transactions should be flowing through the system and why the problems might be occurring. Sometimes it’s just a problem with the customization, but often it’s a lack of understanding of how the system functions that leads to problems.
As the consultant who is responsible for upgrades in our company, nothing makes me sweat more than having to upgrade a customer where GP has been heavily customized, and even worse is when it’s been heavily customized and no one seems to know what the customizations are, so as the article suggests, document the heck out of the customizations as they’re made. In most cases where the customizations are fairly minor and conform to summary point #3 – the customizations are updated by the update process and everything works when you test in the new version. But when the customizations are more complex, don’t update automatically, and have to be updated to conform to the new version, knowing the purpose and method of the customization makes the process a lot smoother.