Unraveling Software Configuration vs Customization
August 4, 2011 at 9:00 am 2 comments
Laura Murphy
One of the common themes I heard during NAEM’s EHS MIS Workshop last March was the question, “Was this configured or customized?”
While presenting to her peers, Patty Miceli used an analogy to describe the philosophy on software customization that her team practiced during the implementation:
“Customization is like shopping at Niemen Marcus. It’s fun to walk by and look in the windows and maybe even go inside and look around. But my experience (and my husband) always tells me to put that credit card away and keep walking.”
Following this anecdote, along with the chuckling, I noticed a lot of head nodding around the room. In presentations thereafter, someone in the crowd invariably raised their hand and asked if the system (or a specific feature) was configured or customized. It was clear the general audience accepted this as an important question, and it also seemed generally accepted that “configuration” was the right answer.
But I had to wonder, does everyone truly understand this technical distinction?
I was surprised that this question was never raised or discussed. If that is because everyone understands this distinction, do we all accept the same definitions and differentiators? Is there a common understanding of the specific pros and cons of each approach? Is everyone who asks this basic question able to drill down to specific questions that reveal to what extent a system would need to be configured and customized to meet their objectives? Because without this understanding, the basic question is arguably a vague one open to much interpretation.
These uncertainties led me to a discussion with our Chief Architect, Jack Jones, and some of our customers who were in attendance at the workshop. We decided to write a white paper to outline the facts as well as our perspective on the subject.
In a nutshell, yes, the generally accepted rule is to avoid customization. This will keep your implementation simple, your costs down, and your upgrade path unconstrained. However, there are certain circumstances in which some level of customization may not necessarily be the wrong answer. If customization is determined to be necessary or add sufficient value, the key is to understand how it is managed within the infrastructure of the core system, and exactly what the implications and risks are for implementation, maintenance and support.
What are your experiences with customizing or configuring software to fit your needs? Any lessons you think could be valuable to those going through the selection or implementation process today?
Laura Murphy is the Director of Product Development at KMI with more than a dozen years in the EMIS industry. She is a passionate believer in user‐centered design and data visualization best practices, and specializes in system design in Incident Management, Audit, Compliance, Training and Sustainability.
Entry filed under: EHS Management, Uncategorized. Tags: EHS data, EHS data management, ehs metrics, EHS MIS, EHS software EHS software solutions, EHS software systems, EMIS, environmental management software, health and safety software, software configuration, software customization.
1.
Rick Lebherz | August 4, 2011 at 11:50 am
Thank you for sharing this one. As a sales person for EHS and Sustainability software we use these terms often, and it is nice to know that some people understand their is truly a difference. IMHO it comes down to configuration means we have what you need today, but we have to do some minor changes to make it work for what you want. Customization means we have don’t have what you want and will have to build it special for you.
I also agree that while configuration is preferred some customization might not be a bad thing depending on the overall value it will add to your organization.
Another key aspect along those lines to keep in mind, and ask is the process by which both of these happen and the general timelines associated with both. Then try to keep your vendor honest and working towards those dates. Some software applications are a pain to change anything, if you want it this is what you get. If you want to change anything we have to make changes at a pretty deep level in the application which means developers time and resources are going to cost you. Other applications have considered the need for flexibility and making some pretty standard changes and ‘configurations’ without having to really get deep into the program.
I would use the analogy of customizing a truck. If you are unable to find that exact model with the features you want/need, you should prioritize based on what you know you have as is and what will need to be done. What is the level of effort and how much time and money will it cost to make changes you want to make. (also keep in mind wants vs needs) If you find one that matches all your criteria except the lift or the tint, those arent huge factors. But if you buy the base model and try to make all the changes, it would take more time and effort to get what you want.
Good luck to everyone out there.
2.
tanyacharles11 | August 4, 2011 at 7:56 pm
Thanks for this great article. I believe that to truly break the mold into sustainable innovation come customization is necessary. One thing to make sure of when you are deciding between customization and configuration is that you have done your research. Make sure you check to see if anyone else has done a similar implementation, and make sure the company is willing to support any customization with upgrades!