Over the years that I have worked with Great Plains and Microsoft Dynamics GP, I have seen (and written) many customizations at customer sites. Some of those customizations are in the form of products to handle specific vertical markets or generic tools to enhance functionality. Some of those customizations are in the form of customer specific Dexterity or Visual Basic for Applications (VBA) code.
I have seen systems where there is almost more custom code that original code. And I have seen the pain that can be caused by too much customization. Pain caused by trying to get a system work in a way it was not designed to work. Pain caused by customizations breaking core functionality. Pain caused by customizations preventing the installation of upgrades, service packs and hot fixes. Pain caused by having to maintain customer specific customizations every time new Microsoft Dynamics GP versions are released.
While some level of customization can make the system fit better or run smoother, there is such a thing as too much customization. Don’t get me wrong, Microsoft Dynamics GP has some of the best architecture and tools to allow for easy customization and I love using them. Well written customizations will not break core code, will not have issues with service packs, etc. and will be easy and quick to upgrade. However, we need to be smart about what we customize. We must not customize for the wrong reasons.
This brings me to the great article on MSDynamicsWorld.com by Mariano Gomez, The Dynamics GP Blogster. Mariano discusses 5 wrong reasons for customization and makes suggestions how to handle them. Please click on the link below to read the article. You will need to sign up for a free account if you don’t already have one.
My previous article on this topic can be found at Before you Write a Customization, check Solution Finder.