There is a difference between customization and configuration.
BY ERIC COOPER
So, you’re evaluating software packages and request a sales demonstration. During this demonstration the sales rep is going to focus your attention on the cool, “shiny” aspects of their system and there will likely be a lot of “talk” about how the software can be implemented to meet your requirements. The key question you want to ask is “how”. How will this software be configured to meet those requirements?
This is where the 80/20 rule comes into play. The best case scenario is that the software you purchase will only meet 80% of your requirements and that the other 20% will have to be achieved through some sort of customization, modification, or configuration. In some instances the gap could be much greater. The key then is to figure out how that 20+% are accomplished. Here are three questions to ask:
1. Is the base code altered?
2. Who performs the customizations?
3. How do these customizations affect future upgrades?
There is a difference between customization and configuration. Customization implies code changes. Customization is also generally done by the vendor. Some vendors consider this their bread and butter. They’re basically selling you half a system and then charging you to create the other half. Customization can also prevent you from applying future upgrades without shelling out even more money to the vendor to reapply your customizations. Configuration implies no code changes and is generally performed by you, the customer. As such, configuration changes should not affect future upgrades. However, again the key words here are “should not”.
This goes to the substance of the system. The best systems in the market are the ones that allow you, the customer, to perform configuration changes on your own. Keep in mind that this is not only a factor for your initial implementation, but also for future growth and change of the business requirements. Maybe the vendor will only charge a nominal fee for the initial customizations, but what happens when your requirements change?
Having been involved in a myriad of software purchases, I can tell you that the differences between packages can be great. At a former employer of mine we implemented a document control system that probably only met 60% of our initial requirements. However, the business unit was wowed by what they did see, and therefore we were pushed to approve it. When it came time to do the implementation, the next 40% of the requirements needed customization, which meant that the vendor provided core code changes. Jump ahead five years now. Several upgrades have come out from the vendor and the business decides its time to look at upgrading. Do you see where this is going? In order to apply the upgrades all of the customizations would have to be evaluated and then re-created after the upgrade. Care to guess how much the vendor wanted to perform this job? We’re talking at least high six figures.
So take it from someone who has been there and done that. Make sure you get straight information from the vendor regarding configuration vs. customization. Your initial cost of purchase may seem very attractive, but the long-term total cost of ownership may end up being extremely high.