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.
Great Blog post. I am going to bookmark and read more often. I love the Blog template if you need any assistance customizing it let me know!
VB,
This really hits home for me. We are an ISV in Indianapolis, IN that specializes in Job Cost Accounting. We have an Add-on that is built on top of the “Job” Granule. (Job Manager) After 10 years of enhancements and improvements we think we have a very cool solution for Job oriented companies. However, many NAV resellers still think they can customize a solution for the end-user for less money than purchasing our Granule. ($6,700) They can bearly get started for that amount of money. Thank you for supporting the ISV Channel and pointing out the industry expertise that the ISVs bring to the table.
Rick: I’m glad to find out you agree with my points above. I had a chance to work with several add-on solutions in my career, and the industry expertise was an important success factor. Actually, my primary goal is not to support the ISV Channel (I do support it, really), but to ensure project success. IMHO, there are much more chances of success with implementing existing solutions, than developing new ones. On large scales it is choosing an existing ERP system over developing it from “Hello, World!”; on smaller scales it is deploying an add-on instead of developing extensive (and expensive) customizations. In both cases customers benefit from: decreased cost due to economies of scale of product vs. solution development, industry best practices, horizontal best practices, maintenance & support and upgradeability. If I look at the scale of effort, customers who chose an add-on are generally happier with their solution, than those who “knew it better” and decided to custom develop everything, and generally spend much less money and break even faster than those who invested huge amounts of money into development.
Hi Vjeko, interesting post. I find there are two challenges in using add-ons. First they’re hard to find. The solutions catalog has hundreds of entries (I only looked at the one with over 2000 entries) and there were a lot to wade through to try and find a good one. Then it takes a long time to evaluate the add-on. Then you need to try and get a response from the Vendor and in a lot of cases, they are not interested in supporting resellers or answering questions – on occasions I have struggled to get a “so-called” add-on vendor to answer a single e-mail about the price of their add-on. The second issue is in relation to support. My experience of these add-ons is that the vendors typically see this as a way of making money out of their existing IP but are not seriously in the add-on business. This means they do not necessarily have dedicated teams, they do not upgrade the add-ons and they do not provide support. They will however be happy to take your money for what is often a poorly-documented poorly designed solution. I think that as well as having a Certified for Dynamics accolade for the add-on, the vendor should also need to meet certain criteria to ensure they are suitable and not just making more money. We (some colleagues and I) recently suggested their being a place where consumers of an add-on can rank it and the support they receive from the vendor so that it is easier to find a suitable one.
Dave:
I’ve expected this kind of response (not specifically from you, but from somebody). Actually, you are absolutely right about both challenges.
About the first challenge, it really is hard to find a good solution. But you can always ask Microsoft for help: your PAM or PTS or somebody in charge of you in Microsoft can inquire internally about implementations in a specific vertical, they can also submit a reference request (again internally) and find about which add-ons were implemented. Then they can get in touch with proper PAMs or PTSs of the partners who implemented the add-ons and find out how successful the implementation really was. It may take a while, but if it helps you find a right solution, it saves you a lot of effort and risk in the long run; and if it doesn’t help, at least you know you did your best.
About the second, again you are right about some of them, maybe even majority of them. But if you do steps I explained, you can easily eliminate them, because bad word of mouth will reach you and you’ll know not to do business with them. However, there are ISVs who really specialize in add-ons, and only do these add-ons, invest into them and sell them the way products should be sold (not just to squeeze another buck out of their IP). I’ve had a chance to work with both kinds of vendors and I’ve seen them really work their bottoms off trying to make a decent product and provide you proper support and documentation, and I’ve seen the opposite kind, those who’ll “be happy to take your money for what is… a poorly-documented poorly designed solution” (as you say).
If it happens, as you say, that these vendors don’t reply to e-mails, don’t provide you with a quote, documentation, demo version, etc. then you move on–they aren’t worth your time. But I am sure that for almost any vertical you can find a decent vendor. If you find such a vendor, I believe the benefits I explained really stand.
Hi,
I have both good and bad experiences with Add Ons. Since some of my views have already been voiced in earlier comments, I would like to comment upon what can be done.
1) Micrsoft encouraging registration of Add Ons from partners is good but some official channel should be available to guide Partners upon selection of Add Ons. This should not merely go by the offerings of the Add on but also by the history of the Add On. Things like: 1) No. of customers presently and successfully using the Add on. 2) Support history of the ISV 3) INfo on upgrades 4) Exact functionalities available ( surely not the Intrucutory documents. 4) An easy database to be able to search on the basis of objective requirements.
As the blog writer says: Even I do see the benefits of going for an Add On. Optimization is the key.
Hi Vjeko,
Your blog posts are as always a joy to read.
Whereas I agrees with you that add-ons most often are the right way to go, instead of creating your own custom solution, then there are situations and reason for not doing.
Dave is right that finding the “right” add-on is difficult. Not only does Microsoft’s official “catalog” contain over 2000 “add-ons”, but the tool is not really so great. As Dave, then I have experienced that the so called add-ons really only are customized solutions made for a single customer.
And most of the add-ons I have actual seen (even the ones who claim that they have been certified by Microsoft) are often badly documented, or do not follow even basic programming standards such as always developing in US-English and adding local languages after. The most recent add-on we purchased in my company we had to rewrite completely (changed about 90% of the objects of the add-on) before it could be used according to our standards.
In the Dynamics User Group we’ve just created an Dynamics NAV Add-on Catalog” and a Dynamics AX Add-on Catalog.
So what do we think that we can do different. Really not so much. But it’s our hope that the community will see this tool as their own, so that the add-on developers add the add-on to the catalog, and the members are given a chance to rate and write reviews and comments about these add-ons, if they know them. So an add-on with a high rating and good reviews should be better.
Dharmendra, Erik:
You are absolutely right, as Dave is – finding good add-ons is difficult, and any tool which could assist customers in doing so would be more than welcome. Definitely some criteria should always be taken into account when evaluating, such as “how many customers have successfuly deployed the add-on, and are willing to endorse it”. However, this might be unfair towards those who are developing add-ons and are just launching them – they don’t have any customers, and have to fight a tough battle being found, chosen and implemented.
Eric, your observation that many “add-ons” are actually customizations that their vendors have decided to monetize beyond original project – I’ve seen these too. Personally, I believe this doesn’t have to be a problem, as long as the vendor has a dedicated team of people maintaining such add-on. If they don’t, then they are worse than customizations, because their support costs in the long run can easily exceed the cost difference gained on not customizing NAV. However, again as you point out, Eric, if this is the case, you might end up customizing the add-on heavily, which again cancels the cost benefit it should achieve.
My criteria would always be along these lines: does the add-on vendor specialize in the add-on business, or do they just do add-ons as a side-business to their principal consultancy/implementation practice? If they don’t focus on add-ons (even exclusively!), then this is a clear warning sign and a huge risk factor. If they do – their add-on will probably be a better choice than custom development.
There are several companies which do nothing but add-on development and delivering their business expertise in their add-on implementations. You can’t possibly beat them on quality, cost performance or schedule, with any kind of custom development–when their add-on is needed, they are truly the best possible choice.
I’m so glad that this article has ignited this discussion, because most of the risks of the add-ons have been exposed.
Vjeko,
Taking a look back on companies who have been/are succesfully delivering add-on’s for NAV, ex. Celenia, TopSolutions, Lanham, ShipCentric (and many others). They all started their business as “normal” Navision partners, but at some point in their history they found out that if they should continue to expand their business, then they needed to do something different. They have all either sold the “normal” Navision reseller part of their business or moved their add-on activities to a separate company.
The problem as I see it, is also that most NAV reselling partners are actually looking at add-on developers who are also selling directly as competitors.
So if we should list what it requires to be a succesful add-on provider then it would be:
You must be 100% dedicated to your add-on(s)
Which means:
1) You should not be selling the add-on (incl. the services) directly to end-users
2) Your resellers can trust that you’re not “stealing” their customers
On the other hand, I don’t say that it’s wrong that a reselling partner start selling an industry solution as an add-on, they just need to realize that it’s not that easy, if they are not dedicated.
Hi Vjeko 🙂
I think than one more thing should be told about implementation of add-on’s -> localization. If you add localization cost and cost of maintaining localization to cost of add-on solution, it rarely is worth implementation.
We localized and maintain localization of few add-on solution and I assure, that it should be a big add-on with potential in sales to decide to do it.
Hi Tomasz: you are right about two things here.
First, localization does add cost, but both localization and localization maintenance costs contribute with a fraction to the total costs of the product. However, it depends largely on what belongs to the localization: any country specific regulatory functionality, or just language translation. Translation shouldn’t be a problem at all, and with proper planning its costs can be kept at minimum. Regulatory localization can definitely be a problem. But again, add-on is the same as NAV itself, only on much smaller scale; if you commit to a product, and focus your business to building and maintaining a product (and willingly decide not to try to do implementations at the same time), then it has much more chances of success.
Second, sales potential has to be an important factor in deciding whether to do an add-on or not, as with any product lifecycle management. I would say that commitment to the product is what keeps its cost down–if you decide to commit to the add-on sales, and focus your energies there, you can easily become “the” product for certain vertical, and shouldn’t have any problems selling it. But if you do, as other commenters mentioned here, engage in generic NAV projects in addition to maintaining an add-on, then your add-on most likely won’t succeed: your energies will be mostly focused on implementation projects, while they are needed in product marketing, sales and support in order for your add-on product to establish and retain a sustainable revenue chain for you. It’s typical product vs. solution story: both are viable business models (obviously), but both can’t be done at the same time by the same people. If a single company does both, then they have to have separate and 100% dedicated teams for product and solutions. If they don’t, both product and solution quality will suffer as focus shifts, it will be dificult to achieve economies of scale, it’s likely that they won’t build enough industry expertise, in the end meaning much higher product costs, which in the end means less sales, and less point in having the product in the first place.
Anyway, it’s nice to see you here!
I rather mean partner’s costs, because (but maybe I’m form too distant country 😉 ) ISV seeks partners to localize their products for given country and I’m talking from such partner perspective.
Anyway, I think also some scale factor should be added to discussion, because there is difference in ratio “localization cost/developing replacement cost” between let say “LS Retail” and small “interface to banking systems” but still both products are add-ons and are listed in add-on catalogue.
My point is, that I can agree, that to use add-on is an good solution, but it should be always considered, if it is worth in specific situation. Specially if there is no suitable add-on already localized (or developed locally) and we should consider localization costs (including learning costs, translations etc.).
If a partner is doing localization, then partner should bill these costs to the customer. It should still be much cheaper for that partner to localize the product, than to develop it from scratch, even if they never again re-sell that localization to anybody else. Now that you mention LS Retail – how much do you think a custom development (and maintenance) of such a functionality cost, compared to localizing it? It is cost-effective for both the customer and the partner.
About scale, you are absolutely right, localization of smaller add-ons might easily cost more than a from-the-scratch development. And here is a hole in my original article: smaller add-ons don’t really offer all those benefits.
I also agree with your point, and as I said in the post, “it’s not all black and white”. It really isn’t. The point of my post was to emphasize the benefits that add-ons offer, which are often overlooked.
Well, I think choosing an addon or doing customizations depends strongly on the quality of the addon software and on the support, the addon selling company is providing (for example concerning bugs,…). I made the experience that the more often an addon has been sold, the fewer will be the problems you can get into with it. There are really already some “standard-addons” at present, escpecially in areas like payroll, electronic payments or EDI, e. g.
But one point is worthwhile being discussed: there is always the possibility that the addon selling company decides from day-to-day to make acquisitions (concerning updates, e. g.) to end-users directly (the market is rough) and perhaps you will not be the first company to lose some customers along that way…
There is yet annother aspect concerning addons. Since the pure standard NAV may cover about 80 to 90 % of the customers needs, using an addon may raise this portion to 95 %, but I rarely found an addon covering 100 % without the need to customize one thing or the other…
Hi Vjeko, I tried the link to find the add-on catalog and it is not longer there. You may want to update the post with this URL http://www.microsoft.com/dynamics/solutionfinder.mspx. Cheers, Dave.
@Dave: thanks for reporting this broken link to me! I haven’t noticed this. They must have removed the downloadable PDF version, I also wasn’t able to locate it, so I’ve now put this link you gave me.
Hi!
Recently I found dowloadable version of Add-on Solutions Catalog – you can find it in Microsoft official website
here.
@Stipe: thanks a million! That’s the document that was linked here in the first place, only it was moved from its previous location to this official MS Download site page.