Use of standard components in NAv implementations

tdoelmantdoelman Member Posts: 5
Throughout my different jobs in the world of NAV, I have experienced again and again that NAV partners tend to object to the use of standard components in the form of proven add-ons. Statements often heard are "we have something for that ourselves" and "we can easily make that ourselves". Those statements may be true for the moment, but will they remain true in future, when this functionality needs to be upgraded along with projects and/or NAV releases?

I would like to hear why the majority of the NAV channel is sticking to this system of inventing wheels over and over again, with all the dangers of excessive (non chargeable !) time to be put into development of something that is already there, uncertain outcomes, danger of dissatisfied customers etc.

Please comment.

Comments

  • einsTeIn.NETeinsTeIn.NET Member Posts: 1,050
    Because they do not know!?

    I believe because of a very low baseline level for change something in NAV everyone could do it. But programming especially in NAV is something that has to do with experience. If you have a problem within Office you will maybe search for an Add-On and/or accept that there is a problem. Sometimes you will report it to MS and hope that they will fix it in the next release. You wouldn't even think about creating your own Add-On. In NAV world informations and solutions are spread all over the planet and in the strict sense ISVs are competitors. So, I think some imformations are hard to find, some are available but you didn't ever heard of, some are a well kept secret, ...
    "Money is likewise the greatest chance and the greatest scourge of mankind."
  • FDickschatFDickschat Member Posts: 380
    I think einsTeIn.NET is perfectly right.

    From previous projects experience I can say that sometimes it is really worth it buying a module but not always. It's usually when the module fits 100% and you don't need to modify it.
    There are still NSCs who will block objects against modification so that no other NSC can modify them (competitor thinking).
    Then there are NSCs who have a nice looking module but under the hood it is the most terrible programming you can think of (seen that myself). And you only discover this after you have bought it at the time you want to modify it to your needs.
    There are even NSCs who will not sell a module to you because your license is with another NSC (of course you could transfer your license for a week to NSC B, buy the module and then transfer it back to NSC A).
    Frank Dickschat
    FD Consulting
  • lvanvugtlvanvugt Member Posts: 774
    A perfect valid question you pose and which I am posing myself every once in a while. Due to the various roles I have been in, due to my character, due to ...

    You might have read my last blog post which is adressing a bit similar perspective as einsTeIn.NET takes. I really abhor reinventing things that are already there and have a proven track record. That's a personal preference but also because our ...
    as I wrote:
    ... customers are in need of a solid and sound solution, not a piece of art.
    And yes, some people have difficulty to trust others so either buy from or sell to them.
    Luc van Vugt, fluxxus.nl
    Never stop learning
    Van Vugt's dynamiXs
    Dutch Dynamics Community
  • kinekine Member Posts: 12,562
    I think that one reason is responsibility. Your partner is responsible for your system and using some addon from another partner could be problem in this responsibility, because they have warranty with you and if something is problem in this addon, they need to solve it with the second partner. This could be problematic. Having own addon for this, they are the one with know-how for this addon and could solve possible problems more quickly.

    It is problem that when you want to use addon from someone else, it is black box for you and without deep knowledge of the inside it is big risk to use the addon for some customer...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • einsTeIn.NETeinsTeIn.NET Member Posts: 1,050
    Responsibility wouldn't be a problem if all ISVs would have the same standard and the same ambition to their product. If you're sure that a third party product will be improved and supported as well as you would do to your product then you would rather give it a break than develop it yourself. If you wait for an answer from a third party and your customer calls you again and again to ask what's going on then it might seams like you're tardy. So, I think it's also a question of trust.

    On the other hand if you make a deal with a third party that the customer is allowed to contact them in a direct way then it might be that everyone says: No, that's not a problem of my product, please call the other producer. That's again subject responsibility, but this time the other way round.

    Or the customer didn't know which part belongs to which product. And what about side effects that will only appear in certain combinations of two or more products. I believe this topic is too complex to find one solution.
    "Money is likewise the greatest chance and the greatest scourge of mankind."
Sign In or Register to comment.