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.
Very nice post. From the Dynamics GP side I would also add Improvements. I frequently see companies customizing a new ERP system to act like the system they are replacing. You know, the one they complain about, can’t make work and are generally unhappy with? A new ERP system is the time to look at all those assumptions, processes and limitations from the old system and figure out how to make them go away.
Mark
Mark, I totally agree with you on this. I also can’t stress out to my customers how important it is for them to rethink their processes, because there is no better moment do to that, thank the ERP implementation. The “our old software” sindrome is far too common, and there is no better cure for it than plain, standard ERP, whichever the flavor, Dynamics or other.
I generally agree however the Microsoft Dynamics AX (Axapta) platform with its 100% Object Oriented Integrated Development Environment (IDE) is nicely suited for building vertical applications. Many AX customers get themselves in trouble by modify too many objects necessary to achieve horizontal customizations. Microsoft almost always enhances those objects with each major version which means conflict when you upgrade. If you create new objects for vertical customizations then they should upgrade without any conflict. Be insightful and mindful on the number and kind of customizations using the Dynamics AX (Axapta) platform.
Hi Babic,
Your article has given me a whole new dimension to think of an ERP Customization. I do not argue for unwanted customizations, for sure, but with this article, now I am going to think twice for any customization as such.
Thanks for this insight.
Thanks
Vaidy
Vaidy: Thanks, that’s what I hoped to do–to give people insight that they don’t always have when doing implmentations. Implementations themselves are risky enough, too many customizations just introduce too many unnecessary risks, and there are better approaches, about which I will talk in a future post.
AXManufacturing: Vertical add-on is not the same thing as customization, and they are definitely a preferrable choice. They work a little bit differently between NAV and AX, but generally their advantage is that they are developed and maintained by a company who generally specializes in them and doesn’t do implementations directly. By choosing a vertical add-on, a company mitigates majority of the issues I discussed here in my post. What some customers do, however, is that they give up on an add-on and decide to develop the vertical functionality specifically for their project–such customizations have high risk of failure and introduce long-term maintenance costs.
Both: Thanks for comments, and welcome to this blog! See you around!
Great Post. Customizations should be seen as a last resort. Also its important to understand at what layer to customize. In GP you can go from triggers, dexterity, VBA, etc. It is important to customize at the right layer
Felipe: welcome to the blog, and thanks for comment! I’d say that with NAV it’s the same story: there are many layers that you can customize, and you must take good care about what to touch, and what not to touch. In my book, I’ve explained how to do customizations so that they have little impact on upgradeability.
Erik: I am not sure that the criteria you listed (about the competition, and “stealing” customers) have anything to do with being 100% dedicated to add-ons. It’s definitely bad practice to “steal” customers, but I wouldn’t say that you shouldn’t ever sell services directly to end-users, provided that these services are about your add-ons, and not about general implementation. If a customer decides to hire you, and their partner does not object, then it should be ok. When it is about general implementation, I totally agree – it’s something that add-on vendors generally should not do. But I am sure that most of serious add-on vendors are very well aware that they can make more money and deliver more quality if they focus on their add-ons and leave implementation projects to other companies, and most of those that you listed actually did that, successfully.
I totally agree with you, but with Microsoft dynamics GP we are facing a big problem regarding record level security for multi branches organizations, because GP does not have such security privileges for each branch to secure his data from being modified by another branches like (customers, vendors, checkbooks, SOP types and sites), so could you please inform me how can I secure my customer’s information without customization those windows? Thanks
Yehia: I don’t know much about GP, but the guidelines I gave shouldn’t ever be cast in stone. If you have a valid reason for change, by all means change. What I was primarily arguing against in my post is “customization by default” approach, under which just about everything is customized–something that I’ve been seeing around a lot. In NAV, you have security roles that can take care of record-level security, I don’t know if something like that exists in GP. If it doesn’t, then modifying forms (or windows, I don’t know what’s the correct GP term) might be the only solution, and in this case it might be a valid reason to do this modification.
If you need a good GP blog to look for the answer to your question, I suggest Mark Polino’s excellent blog at http://msdynamicsgp.blogspot.com/
Manual trackback:
http://niiranen.eu/crm/?m=200902
Pingback: Week Five | hissah6104317308
Pingback: COIS12073 « Tom loves Jerry
Pingback: Week 04 | ardeshirmir
Pingback: Week 05 | ardeshirmir
Pingback: Week 5 | ERP Discussion Blog
Pingback: Week 5 : Don’t Customise & Ass2 Skeleton | This Blog discuss about ERP Concepts.
Pingback: WEEK 5 | santoshrao111's Blog
I completely agree with your opinion about the topic of customization excess in the erp-system. From my point of view, the main reason is upgrade, because it really often requires re-developing all the customized functionality, and you have to pay for the same customization after every update. I think it’s not practical.