Implementation is like marriage. For better or worse, you choose a piece of software, take it under your roof and commit to it for a long term, so help you God.
And as in marriage, if you want to live happily ever after with your new software, the my way or the highway attitude doesn’t help much—you must be open to compromise.
Last Monday, I argued for avoiding customizations if at all possible, an argument I stand by firmly. It’s like forcing your wife to color her hair pink. I don’t know about your wife, but mine doesn’t color her hair pink. If you like it pink, it’s probably something to think about before turning your yes in.
But NAV is NAV, isn’t it? It has what it has, and if I need it different, I have to customize it, right?
Wrong. You can compromise.
There are two other approaches: changing your processes (which I discussed already), and choosing an add-on solution.
An add-on is a module developed by a third party (not Microsoft and not your implementation partner) and designed to address specific needs and provide functionality not existing in standard Microsoft Dynamics application, or extend existing functionality. These add-ons can be “horizontal” (not industry-specific) or “vertical” (industry-specific). There are more than 2,000 add-on solutions for NAV, and about 550 are listed in the current version of Microsoft Dynamics NAV Add-On Solutions Catalog.
I strongly believe that choosing an add-on solution for your specific needs is a better choice than developing complex customizations. Add-ons are better against all three sides of project triangle, take a look:
- Time: as obvious as it can get, it takes several orders of magnitude less time to deploy an existing solution, than to develop a custom one. That’s precisely why you chose to implement NAV instead of developing a yet another ERP from scratch.
- Cost: see above. In consulting (and not only there) time equals money, and less time means less money. For add-on solutions you typically pay license cost, while for customizations you pay for development time, and licenses are cheaper. I’ll elaborate on this further below.
- Quality: unless your implementation partner has experience in your industry, you are more likely to get an overall better-quality solution if you go for an add-on, than if you choose to do custom development. I’ll also elaborate on this below.
So, what about cost?
Principle which drives low costs of add-ons is called the economies of scale. When you are developing something for the first time, you invest a lot of time (and money) into analyzing requirements, designing, developing and testing. You do it for add-on as you do it for a customization. To this point, these two cost exactly the same (provided the scope is exactly the same). But the add-on then takes a path which can keep its costs down over longer run: re-sales. It is sold over, and over, and over again, the margin is designed to be earned over a longer period, which means that lower price can be charged for any single deployment. On the other hand, one-off custom developed solution is sold only once, and it must generate margin that very once.
A consultancy which only does custom development on their projects, and never deploys any add-ons, will soon find itself maintaining dozens of custom solutions: this asks for a tremendous effort from them. It also drives high costs of maintenance, because they can’t afford to have a specialized person, or team of people, to maintain a single custom solution. They usually have the opposite: one person maintaining several custom solutions. The less specialization, the less efficiency, the more costs. Since not all maintenance costs can be billed, some of these costs are built-in in the cost of implementation itself. When not, you end up paying expensive support plans, or expensive support incidents.
Add-on vendors have a completely opposite scenario: they have teams of people maintaining a single solution, all of them specialized in it. The more specialization, the more efficiency, the less costs of support. These costs don’t have to be built-in in the license cost, they can be paid as maintenance cost, which is again cheaper due to economies of scale that add-on vendors can easily achieve. Furthermore, the more their solution is implemented, the more issues they will encounter, and they will gradually build a knowledge base which you can leverage when you have a problem: a lot of problems can be resolved at the point of contact.
Finally, the industry expertise. Add-on vendors are often specialists in their industries: they know the industry inside out, they have likely seen hundreds of customers just like you, and have solved their problems—the same problems you are facing now. They can bring you a bit of this expertise when you choose their add-on solution. A unique opportunity.
Of course, it’s not at all as black and white as I painted it here and in previous posts. Choosing the right balance of process change, custom development and add-on solutions is probably a better way to follow than to simply decide to only implement add-ons, or not to do any customizations, or to only adapt your processes. It’s important to bear in mind all the options, though, and what they mean for you, time-, quality-, and cost-wise, in short and long runs.
Now, there is comments form down there, it does two things: it doesn’t bite, and it lets you express your opinion—take advantage of it and share your thoughts, just as I did above.