In my thirty-six years at Fenwick Software I have worked with many clients, originally doing custom-development then moving into implementation of packages, most recently Microsoft Dynamics NAV.
NAV is a mature product and meets most of the core requirements of our clients. Our Fenwick Gold modules extend and improve NAV’s capabilities. There are also many add-ons for NAV that provide targeted functionality for a broad range of industries; enwis) is a prime example of this, extending NAV to suit the special requirements of the waste and recycling industry.
People purchase packages for a number of reasons:
- More ‘bang for your buck’: developing your own system from scratch is expensive and risky (Myki, Ultranet anybody?)
- Reduced risk: a reputable package has been thoroughly and rigorously tested
- Long-term improvement and support: the package provider is continually investing in its product and adding new functionality. For example, when the Goods and Services Tax (GST) was introduced in Australia, an updated version of the software was available well before the implementation of the new tax
No package is perfect, and many businesses require (or think they require) changes to the software to meet their special requirements.
However, no package is perfect, and many businesses require (or think they require) changes to the software to meet their special requirements. These changes come at a cost. Every time you upgrade, these changes need to be upgraded too. There is also the risk that the changes could have unintended consequences and cause problems in the future.
If you require major changes then you seriously need to question whether your selected package is the right one for you. On the other hand, sometimes your business has unique requirements which mean that no standard package will be suitable. If you do fall into this category, you need to carefully assess the capabilities of both the package and the company implementing the package. The best package in the world implemented by a sub-standard implementation team will, in all likelihood, fail.
Minor changes can sometimes significantly improve functionality and usability. On the other hand, they can be adding unnecessary cost and risk to the project. However, it is also often the case that small changes to a company’s processes will allow it to utilise the standard functionality of the package without the need for modifications.
My advice to my clients is to carefully assess the cost, benefit and risk of any modification. I also recommend that, unless the modification appears to be absolutely necessary and there is no practical workaround, we note the request for change in a Change Request Register and review the list 2-3 months after going live. It’s surprising how often those ‘must-have’ mods turn out to not be necessary.
