Top 7 reasons why to avoid (much) customization

To customize or not to customize, that is the question. When you see a complex business process far from the standard ERP system, a knee-jerk reaction is to reach for customization tools and do the development.

Many ERP theorists say that ERP is only as good as it is an exact match for your processes. And they are mostly right about it. But majority of ERP systems are very generic (Microsoft Dynamics NAV included), and to exactly match your processes, they require customization. When it doesn’t work out-of-the-box, you customize it, it’s that simple, isn’t it?

It’s not, sorry.

For every inch a customization brings an ERP system closer to the way you do business, it makes it an inch farther away from what it really is: a named product you purchased in the first place. It might not matter to you at this point, all you need is solving your business problems after all. But solving business problems can introduce new non-business problems, which cause you so much pain in the long run to become business-relevant.

Here are what I believe to be the top reasons why you should avoid customizing your ERP solution:

• Regression: this is a fancy term of software development theory which is really used as an euphemism for “a screw-up”. That is when you do a small change to functionality A, and suddenly functionality B starts behaving funny. When you introduce a new feature, you must do the regression testing to make sure your new change didn’t mess something up with what was already there. With ERP, no matter what you do, there is a lot of the already there stuff to test. The more you customize, the more regression testing you have to do, and what consultants don’t find, the end users will, but after go-live. Hunting down these goblins goes on for months, and I’ve seen deployments which turned into a lifetime of regression issues.
• Go-Live: customizations prolong your go-live. The more you have, the longer it takes before go-live. Even though your initial budget might have covered for all the customization costs, time overruns can make your project unsuccessful. With ERP systems, go-live dates matter a lot: it is much easier, and less costly, to switch at the end of fiscal periods, preferably years. You miss the deadline and you might need to postpone the whole thing for another month, or another quarter.
• Official support: when there is a problem, depending on your support plans, you might request official support from system vendor (Microsoft in case of NAV). When you do, first thing they’ll want to know if the problem repeats in the standard application. If it doesn’t, you are toast, because Microsoft can’t support your custom solution. For smaller issues, this might not be important, but imagine having a critical bug which put your business to a stop.
• Upgrade: a life cycle of an ERP application version is two to three years, while a life cycle of an ERP deployment is five to ten years, sometimes even more. This means that in a life of an ERP deployment, there will be between two and five (or more) versions of the same application released by its vendor. Upgrading to a new version can sometimes require re-developing all the customized functionality, making you have to pay for the same customization time and again. And then fight regression issues all over. Of course, you may opt not to do any upgrades, but that can mean locking your whole infrastructure to old versions of software (and hardware).
• Know-how: people come and go, but the knowledge comes and goes with them as well. If you use Microsoft Dynamics NAV to manage your business, you have a huge benefit of being able to hire power-users who have experience with Microsoft Dynamics NAV. But if you have a Frankenstein, anybody who comes to your company with the knowledge of Microsoft Dynamics NAV won’t be of much help. And when people who know the Frankenstein leave your company, Houston you have a problem. The same is true for your consultant: the people who developed your Frankenstein might leave, and new people who come, who might be world-class experts in NAV might easily not be able to support and maintain your solution at all.
• Vendor lock-in: one of the benefits of choosing a standardized ERP system is avoiding a vendor lock-in: if you are unhappy with one your Microsoft Dynamics NAV partner, you can switch for another one. Or can you? If your first partner developed a Frankenstein for you, you might have troubles switching partners. Companies are very cautious about accepting to support an application they didn’t develop, they have to learn something non-standard and then to maintain it; it might be too costly. If you have to switch partners, then it sometimes means re-implementing the system. Sticking with your old vendor might be one huge opportunity cost for you.
• Help: you know that handy little F1 key? It often becomes worthless. Really, how many of consultancies update the help file with all the customizations and changes they did? Yes, they give you the operating manuals or end-user documentation, but how handy is it really? Users can’t tell what is standard and what is customization, and if there is help for their Customer Card, but there is no help for their Parcel Tracking List, and if the existing help for Customer Card explains only half of what is there, or when it explains something in a wrong way (because the developers decided to tap into existing functionality and invent a new purpose for it)—your end users will stop using the help file. And the moment they stop using the help file is the moment when they’ve given up. From that moment on, you’ll have them gradually stop thinking and turn into robots following cookbooks, which will cost you dearly in errors, rework, and lost productivity.

When you look at customizations from this perspective, it becomes obvious that customizations can turn your ERP system into a huge long-term cost generator.

Of course, it is not all black and white. Sometimes customizations can be totally necessary. All of the above doesn’t mean you should avoid all customizations, it only means that you should consider the alternative ways, and if you decide the customizations are the way to go, at least you know the risks, so you can better prepare for them.