Monday, April 7, 2008

Why You Should Almost Never Customize Enterprise Software

Why is it that so many large companies will buy an expensive enterprise software package that is missing critical functionality and features for their business? Why do these large companies that buy this expensive software then pay for expensive developers to write customizations to that software that should have been included in the software to begin with. In every case that I have seen, the customization was not necessary and should not have been done. It wasted thousands of dollars and results in unnecessary delays or in one extreme case even compromised the benefits the out of the box software would have provided.
Each customization an enterprise company decides to make should have a strong business case behind it because of the incredible cost it will bring to future upgrades and general maintainence. In other words, each software customization(ui change, feature enhancement, integration piece, etc...) should have a positive return on investment that factors in the cost to maintain that functionality. Most good features should just be added to the next release of the enterprise software and supported by the software vendor. If their are features missing from enterprise software ABC, the first step is to engage the vendor Product Development team and ask for it to be added in and tell them why. Open a feature request ticket, call them everyday, twice a day, until they relent and say yes because phone calls are cheaper than developers.
Good reasons to customize:
  1. It gives my company a strong competitive advantage.
  2. It is legally required, my company will be take to court if it is not included.
  3. It saves my company vast amounts of time or will reduce expenses dramatically.

and, after many attempts, the vendor has told me they will not add it to the product.

Very bad reasons to customize:

  1. My subject matter experts don't want to have to click that. (resistance to change)
  2. My customers will be confused. (assumption / training issue)
  3. I have this exsting system I want to leverage (another form of resitance to change)
  4. I can't wait for the next release to have this feature and the vendor won't backport it. (shortsighted decision)

From day one, installing and rolling out an enterprise software system to replace an existing process (or set of processes) will be subjected to tremendous resitance to change by every department affected by the project. Picture a single person (you) on one side of a rope and the entire company pulling the rope the other direction to get an idea of a typical resistance scenario. Recognising this early and planning for it is critical for a project to be successful.

Furthermore, until the software is rolled out and actually used by the actual agents or customers in an actual work setting or production environment, any beliefs about how the interface will be (mis)understood are just plain guesses. Often they are not intelligent guesses. Often what I have seen is contrived, based on assumptions or imperfect mental models, or, worst of all, problems derrived from sandbox environments where the edge cases get lots of attention and the meatier workflow is left unnoticed or ignored. Until users are forced into the new software, kicking and screaming, the real usability issues will remain hidden. So why fix the UI when you don't know for certain what precisely is broken?

Finally, your existing systems do what they do, any attempt to integrate them with the new system is a change resistance on your part to allow the new system to stand alone as it was intended to operate. You can't always know the impact on the existing system an integration will have, nor should you expect to fully understand the negative impact the existing system will have when it is connected.

Bottom line is the vendor sales agent will probably tell you anything can be done and is possible, and technically they are correct. Just because a sales person says your ideas are great and wonderful does not mean they actually are. Would a car dealer tell you that putting snow tires on your band new convertable mustang was a stupid idea? not if they thought it would cost them the sale! Custom auto shops are glad to take your money to drop a truck's suspension rendering the vehicle a crippled novelty rather than the expertly designed and highly functional vehicle you test drove. Enterprise software is not that different.

5 comments:

Christina said...

Correct as usual.

Can you come preach that message in my meetings the next few days?

Harley said...

can't wait to see the 'bling'

Jonathan said...

it is called software sales people tell the person buying anything. (person buying does not know what they need because they have not ask the people that will be the daily users)
They pay a lot of money for the software& HW Then it does not work. The selling company come in and Hacks it into something that kind of does what is needed. I read about Waste management sueing SAP because they payed 100M for something that did not work.

Hillary said...

My company is 55 working days away from implementing SAP Business One. I am right in the thick of things. We were promised a lot from the salesman and for the most part it has been delivered. Anything that it won't do, I feel that we did a bad job asking the right questions in the beginning. We are integrating it with one application that we already use and it falls under the category of "will save large amounts of time and money". Hopefully it won't come back to bite us in a few years... but that's where you come in, right?

Harley said...

Yes Jonathan is right on. When I worked for Novell they wrote off buying Vignette CMS as a "bad investment" because they could not get it to be a stable replacement for Teamsite CMS. This decision was made after about a year of effort in planning, designing, implementing and even paying to have employees trained to use the Vignette tools. They were sold on Vignette's compatibility with DB2, but in the end Oracle was the only DB that would run the system right. Oracle just happens to cost ten times the price for licensing and using it was not factored in the budget.

About Me

My photo
Lead Java Developer Husband and Father

Tags