I think most regular members here and on
The Dynamics User Group are aware that I am getting exceedingly frustrated at the direction the Navision community is heading. today we finally had a new member asking the right questions (
Timescale of learning Dynamics NAV) and wanting to do the right thing, and follow the rules set down. The question being "are those rules the right rules".
Virtually all major software products are heading down the
"Throw Bodies At It" path see my blog
If it takes one person 10 days to dig a ditch, how long does it take 10 people to dig the same ditch? for my thoughts on that. In addition, we have developers out there trying to be consultants, but since they can't consult they simple do what ever the customer asks them to do and I wrote about that in my blog,
The most powerful tool that a Dynamics NAV consultant can use.. And of course once they start down that track, the consultant wants to make the customer happy so builds a monster, much like the Homer Mobile
What if Homer Simpson became a Navision consultant?. What I try to show people is that Navision is different. There is no product really like Navision where the expectation from day one is that "configuring" the system involves programming rather than parameter setting. The major difference between Navision and other systems as I have seen, is that to have a successful implementation you need one person, a Navision guru; on each project that knows every feature and trick of Navision and knows how to match that to the needs of the client, and when to say no to the client and match their process to what is in Navision. Some systems (such as SAP) require that the customer selects a model that closely resembles their business, and then the business shifts to work with the system and SAP can do this. Some systems (Axapta for example) meet closer in the middle, where the system does most of what you want, but fine tuning can be done through development. But both those systems were designed from the start to be implemented by a team and that team can work without knowing 100% what other modules do.
Of course we are now losing those Navision Gurus for various reasons. The most obvious one is Off Shore development. Navision has an "agile" development environment, where prototyping is a part of development and changes are tested and worked on with the client in an interactive iterative process. Once you bundle up the specs in an email and send them to a team of 20 developers each of which have 6 months Navision experience, and none of which have ever used Navision in a live environment, there is no way you can efficiently or effectively complete an implementation. On top of that, ERP customers are very attentive to hourly rates rather than total cost of ownership, and bizarrely most clients seem happier to pay for 1,000 hours at $50 per hour than to pay 100 hours at $250 per hour.
We all know what happens. Since we see these questions posted on the forums everyday that clearly are from developers with no significant experience with Navision, and no contact to the customer, so they don't know what to do, and they can't interact with the client, and unfortunately they don't even have senior people they can go to for advise.
Other reasons we are losing these gurus, is because of natural attrition. We have many more Navision sales, but there is no new source of gurus. People are required to be billable ASAP, so they never develop the skills that once were considered as a basic requirement. And the newbies can simply ask on forums rather than thinking for themselves. Worse is that many of the new breed of Navision people have Navision as a part time job. They get certified in 5 different products, and then work for 3 years in a company, and at the end their resume shows 3 years on each product, i.e. 15 years of experience, where if they only had Navision they would only have 3 years experience. So in reality that person is the equivalent of someone with 4 months experience but looks like 15 years.
This whole concept of Certifications and Sales as the core of being a partner is wrong.
For some time now most of the people I speak with about this, fall back on the old argument "But this means more work for us", and that used to be true. But not any more. Customers are finally waking up and realizing that they deserve what they paid for and demanding it. So the partner has no budget to fix things, and the bad implementations just pile up, and eventually it just becomes one huge "Ah well at least its working now". Navision is a great product but it needs skilled people to implement, and this fact needs to be a prime driver in becoming Navision certified, and the drive needs to come from the top.
If this does not happen, Navision will start to get a bad name not because the product is bad, but because it is being implemented badly. Today we probably have the same number of good Navision partners as we had 5 years ago, yet we have many more partners. So percentage wise it's not looking good. And since the cost of entry to Navision is now quite low, there is no concern for these companies that if it doesn't work, they can just drop Navision and move on. Remember when being a Navision partner meant that Navision was 90-100% of your business? Drop Navision and you are out of business.
So the question is "as The Navision Community do we have any responsibility to Navision and to our selves, and to our future lively hood to do something?" and of course that leads to the question "Can we actually do something".
(or just tell me that its all in my imagination and that things are great as they are).
PS Note that I have cross posted this on both sites
http://dynamicsuser.net/forums/p/34100/ ... spx#179023
Comments
How easy is it to find such professionals and, even if you do, do you think companies are willing to offer them what they want? I think companies will just skip such thoughts, hire the cheapest employees they can find and just focus in sales and not in quality.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Congrats for achieving that. With regards to content I will answer later...
http://mibuso.com/blogs/alexchow/2008/04/21/my-microsoft-conundrum/
Let's not confuse Microsoft's priority. They're a software company, not a service company. Their focus is on the sale of software, not the service quality. That responsibility falls on the partner.
This model is a good thing for customers because if you don't like the service provided by company ABC, you can easily switch to XYZ. Whereas ERP software companies that also does service, you're really stuck.
The take away from this model is that Microsoft will focus more attention on companies that can sell, not companies that can deliver. In the new partner requirements, I do not see anything in there where you're punished for bad implementations.
For Microsoft's responslibity, they need to sell software, and their partner network reflects this. This will never change unless:
1. Microsoft changes their business model (which they most likely won't)
2. Spin off the MBS division (probably not)
3. Act of God (more likely)
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
there should be A SOFTWARE that is like just an original navision like we know as version 4 upto 5 - that is preserved, not added by many techie buzzie wuzzie things that create tens alternative to get things done.
i'm dreaming you all seniors and seasoned consultants / project managers / developers / system engineers / etc. , who knows navision since version 1 or 2, who were having close relation to former Navision a.g., Denmark, who were in the inner circle of genuine authentic original navision attain upto MBS Navision . . . . . . can announce your collaboration in developing new ERP system, some kind like Navision.
i'm dreaming those people teamed up to a group, and build the old Navision. a new company, a new business model . . . when arrive to a matter of brand trade-mark, just name it as 'avision' or 'Avisio' or 'Avis' or 'Ision' whatever.
i prefer to have Navision college to cook up new consultants. I prefer to have diversification of Navision Consultant companies - that only do consulting and implementation - BUT no development ; then another, we have Navision Development companies - that only do development / customization / and such as, BUT deliver the result to Navision Consultant companies - NOT to end-customer. there might be other arrangement, where the point is customization is initiated by consultant after assessing business needs, and not as what end-customer wants.
then, this community can serve as discussion for navision college member, independent opinion for end-customers, second opinion of business cases, discussing how the customization to be made, and also ... communication board, or job / pros market for the world.
that ... only what's called ... imagination ... and now, my time to wake up.
thanx all
1) Development - core development of the functionality, generic functionality which covers 80% of customers requests in given area (right now done by Microsoft and ISVs)
2) Customization - fine tuning of the generic functionality to suite the customer (done by Partners)
3) Configuration (parametrization) - done by consultants and customer itself (done by Partners and Customer)
wait... ah, it is real situation... ;-)
Biggest mistake is when Partners are trying to do the "Big development" but consider it as customization (all the processes around are like when it is just customization).
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
I believe David didn't what to say to all newbies "Don't ask those stupid questions again and again.". I'm sure he knows that once upon a time everyone was a newbie and that it's one mission of a forum to get newbies to a better start. (Another question is why many people don't have the ability to search accurate before, but that's not the point in this topic.) I believe David wants to point out that in the long run the trend he describes will change the NAV business to something that no one who is in control of himself could agree with.
No, that's not true. I don't want to say that I don't agree to your conundrum post. Some things are true and in the way you describe it I can follow it and your way of thinking. But that's a description of how it is and not of how it should be or could be. Of course we could all accept it, arrange with the situation and act like to benefit from it.
But back to why that's not true. I'm bothered by the switch is easy. I'm working for an end user and from my point of view it's anything else but easy. How do you know to which service provider you should switch? Will he spend more attention to your problems? Will he understand you and your needs better? Does he hold more experienced employees? And is he willing to put them into your project or will you just get his "newbies" as well? And in the end it will cost you a significant lump of money. You have to pay for introduce them to your business and to your company. You have to pay for analyse your processes, although you might have paid for it at your last service provider. You have to pay for technical adaptation. You have to pay for everything. So, to think "Yeah, we could/should switch" is easy, but to do it in reality is very hard.
I know from a friend he switch the NAV service provider of his company serveral times because they weren't happy with the provided quality of service and that moved his company close to insolvency. This dependency is nothing that is good for any business and that's not a thing of either the service provider nor the software producer.
But back to topic. That's the real essence of David's post: If you want to change such a big evolution like this I think this could be a first starting point. But it's more like this. You have to change the minds of the important persons in business. And this will be a process that will last a few years. If it is possible at all.
Thanks
I have come across people who have worked in Navision over 5 years who did not fully understand flowfields and their relationship to the database; who did not really understand dimensions, and so on.
The manuals give you a base knowledge you can build on. The older study program required people to learn the basics in a lot of detail. It is a pity they got away from that.
http://mibuso.com/blogs/davidmachanick/
The fact that you have an option to switch is not available if you purchased an ERP software that also implements. Imagine if you had absolution NO options of switching, what would you do? Stick with a software that's costing you a lot of money to maintain where you can't get the proper support you need?
If you believe finding a new partner is not an easy task. Then it's a good idea to spend the same amount of effort and diligence as if your company is looking for a new ERP software and a partner to implement it. I'm speaking from my own personal experience that customers come to us, 90% of the time we're able to get right in and take over support without a major bill.
Come now.... I highly doubt that this is the cause of his company becoming insolvent. A good manager will keep his business operating irregardless of the circumstance.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
Some years ago there was a big study here in germany that indicates how long a company could live when they had a total system crash. In most cases it was three or four days. But the exciting thing was that one of the biggest companies in the world also takes part in that study and would also just stay alive for six days. It's all a question of dependency.
Microsoft needs revenue from software sales and the community wants good people to represent NAV.
What would you propose to have MSFT should be the new requirements for a brand new company to start selling NAV? It won't do us any good just complain about it.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
there is something that needs to be added to the picture.
I'm conviced that the NAV market is in a bubble: it had a really explosive growth but too many projects have not been profitable or profitable enough and thus this way this growth is not sustainable, it must burst at some point and them some serious restructruring/rethinking of ways will have to happen.
I've seen (f.e. in the UK) NAV partners full with gurus and with intelligent and experienced project and business managers who are still struggling to at least not lose money on project implementations and try to make a thin margin on support and licence.I think it is time to point out - selling standard NAV with those 50-100 days of implementation/customization you can typically sell to small clients is not feasible! I tried that for 7 years in various countries and it just didn't work out. The feasible way is either add-ons or bigger clients.
At some level it is a simple math. My best project - totally calm and stress-free, with happy users and a good solid stream of revenue for us - was a standard NAV + 400 days for a bigger company which has 10 sites with 30 users each. The first two sites were stressful as usual but then the internal PM learned NAV well enough to sort out the usual application consulting chores (setup, training, data migration with my dataports, specifying developments etc.) and thus basically the rest of the days, around 300 were pure development. F.e. when I spent 20 hours on developing a complicated report, they paid it, then distributed the cost amongst the sites, so it was 2 hours per site, which is cheap enough, therefore, they were happy, I was happy, it went well.
Of course - at around 200 days it stopped looking like an big customization and began looking like a vertical add-on - and by 400 days we could have packed that thing up and could have sold it as an vertical add-on because in principle it was one.
The point is - if you have a small client, one site with 30 users, and a standard NAV to begin with, they still need the same features as the big client with the 10 sites because the 10 sites are just carbon copies of each other. Thus the big client does not need more than the small client they will just install 10 copies of the same objects (or maybe just 10 companies in the same db). More importantly - the small client does not need less features than this big one!
Features requirements are NOT correlated with size but ability and willingness to pay IS correlated - this is the most important math to learn in this industry! IMHO.
Why? Because if there is a salesperson who does need to provide a quote printout with a certain structure and content it does not matter if it is a one man department, or if it is 20 people each doing the same thing, or if it is 5 per per site at 10 sites doing the same thing, it is still the same thing, the one-man department needs it just as well as the 10 times 5 men department - but the later are much more willing to actually pay the costs for developing it!
This is the math every NAV partner must learn by heart: the small one will need the same features as the big one but cannot pay for it! Either this math or the add-on math: I might have one-man departments at my customers but I will sell it to 100 other similarly small customers - selling it as a licence and not as a per-day development cost, distributing my costs of development amongst many clients and not just one.
Thus if the big one needed these 400 days it means the 50-100 days one call sell to the small one will plain simply not be enough and the client will be unhappy and demand features for free and no amount of business consulting i.e. "saying no" will help because plain simply it is an objective fact that the software is not fit for their requirements! Plus the small client has no internal IT - so you have to take care of everything f.e. user rights, first-level support etc. it means at the very most half of the days can be used for development.
One way to handle this problem is add-ons. Where I worked before (Middle and Northern UK plus my homeland, Hungary) are not big on add-ons, the culture is just too individualistic, they don't like too much standardisation. (Southern UK does like them. Wholly different story.) So either we got big clients and it was OK or small ones and suffered - because of the above math.
Then I moved to Vienna, Austria (nice place, good food and close enough to my childhood friends in Budapest), and here, just like in Germany, Holland, Denmark etc. there is a strong culture of standardization and add-ons and basically it makes it possible to have smaller clients, because you still need, of course, those 400 days to make something actually usable, for a given industry, but with an add-on you don't have to invoice it all to one client. It was very new to me because I my previous experience was with cultures which are not very keen on add-ons. But basically the add-on mentality is that yes you work 300 days for the first client and they will pay only 50 or 100 but for the second client it will just be 200 days, because you can reuse the previous work, you bill 50-100 days plus the licence for the add-on, still lose money but less, for the third one work 150 days, bill 50-100 plus even more add-on licence, and so on, and at some level in the process you will actually become profitable and keep that way, because you have such a good add-on that you work 60 days, bill 50 plus a nice big add-on licence. So these days in Vienna I'm focusing hard on building up our add-on. This is, as I have learned, the only feasible strategy. I have built a granule for the cost and profit analysis of Jobs which is as complicated and as configurable that it actually requires two separate configuration tables with each being more complicated than the General Posting Setup, but I bet my a** it will almost never need to be customized in code -> we can sell it through partners as some sort of a really finished, finalized product, almost like a "boxed" software -> this is the way forward for NAV partners. Products, not customizations.
Many NAV companies don't get it, I didn't get it for 7 years - thus there is bubble, consisting of many unprofitable projects - it will burst. I predict: within 3-5 years, maybe less, a period will come where hundreds of NAV consultants will become jobless all over Europe.
As for your favourite idea of business consulting i.e. "saying no" - it only works with add-ons. I mean just to use the simplest example in Central Europe there are centralized standards how construction companies electronically exchange data with their customers - quotes, orders, invoices, bills of measurements, everything. GAEB in Germany, others in Austria, Switzerland etc. They simply cannot work without them. Getting it done requires not only building the interfaces, but the general internal structure - forms, tables, business logic, and integrating the whole thing into the standard - hundreds of days. You can find a really big client and charge it all. You can find small ones, but consider it an investment and build it into an add-on. (We did that.) You can find a small one, try to charge it all, and fail the project, or just do it all for free anyway - the worst two options. But "saying no" - will surely not work. No amount of business consulting magic will fill the gab between features that are absolutely required and features that simply don't exist.
We will then make our money strictly from services.
This is the route the hardware manufacurers took when they got tired of competing with Dell.
When I started in business the hardware margins were 30 to 40%.
Microsoft just published their quarterly results. If you look at the detail, the Dynamics area was flat for the year with a 4% growth in the last quarter. All the non-Office products in the Business products division make up 10% of that division's revenue - which puts all of Dynamics, including CRM, well under $1B. Microsoft's original target with Project Green, was to turn ERP into a $10B market. Instead it has become Project Red (as in red ink). So the solution is sell or split Dynamics, or mass market it.
If the current partner revamp project does not work - and it probably won't, because it does not address the real problems - then the mass market approach may well be next.
http://mibuso.com/blogs/davidmachanick/
There was a plan in 2004 for volume licensing and for partners to earn revenue from licenses alone. However how do you keep the current partners whilst at the same time reducing the revenue they make? Additionally the cost of pre-sales and building a partner with the necessary skills and experience is simply very expensive. There are many large businesses out there that are dipping toes in the AX market, but at the same time leaving - if your focus is not Dynamics it is difficult to nod generally in the direction with the staff and skills needed - invest for little immediate return or stay where you are - and many are currently dipping toes. Some are purely selling and using other partners as the service partners - and these are big players - adding to the brand.
I am not saying Microsoft will not do this - they never removed it from the table to my knowledge, however there are many reasons why they have yet to go this way.
Also this will exacerbate the current issue - Your partner makes nothing from license sales, just revenue, therefore the costs of startup and continuation must be less, and therefore employing cheap resource is the simplest and most cost effective solution.
In my opinion Microsoft are still learning about the business ERP market, until they understand what they actually bought into in 2002/3 then they will not make the decision on volume licensing, because the outcome would potentially decimate the revenue stream for them, a revenue stream that is growing year on year. This was the overriding reason why Project Green was shelved, even though from a consumer perspective it made complete sense.
We can blame the great recession, but Office has started growing again.
I think Microsoft will try something to kick start sales - maybe buy more companies. When that does not work, they will go the volume license approach and make the development tools available to everybody in MSDN and a more limited version in the VS Express.
I hope I am wrong, but at some point Microsoft has to start making money on its various losing ventures or drop them.
http://mibuso.com/blogs/davidmachanick/
Moreover they are now trying to reduce the number of partners. I beleive this will be good in the long run......
Last few years becoming a Dynamics Partners was damm easy....When I started my company I was the lone member with virtually no infrastructure other than my laptop and test server. That may not be relevant especially looking at the success story of MS itself but having this as a corporate policy to promote more partners gives me a headache. The attitude is to do more sales and forget about the successful implementation and as few have pointed correctly that MS is still a product company and not a service company. Quality service doesn't even figure in their scheme of things. One more problem that I see is the preference given to big partners. Smaller partners are bullied, deprived of benefits.... and so on. It looks that they are not interested to retain them. Evaluating the performance (Customer Satisfaction) is no criteria. Though smaller partners will prevail but I can see lot of takeovers of small companies in future.
http://ssdynamics.co.in
@Miklos: Interesting view to the business. This will never happen unless there's a significant change in business. Even if your vision of add-ons would become reality then these add-ons are build up on the standard. Thus there has to be someone who is able to implement and support the standard. Maybe the rate of standard consultants to add-on consultants will change but the good ones are able to lern and switch to both sides. And that would mean that there will be no relevant rise of dismissals, at least in germany. I think there will be more dismissals because of a technology switch of microsoft.
Aah, good old times. In some special business areas this is still possible.
I think that's what we can currently watch at the market and what is forcing some of the problems mentioned above.
I am sort of back, after lots of pondering over community and what its all about. Sadly I come back to posts like this Message "You must External Document No..." to be changed and realize that not much has changed.
I realize now that things have changed, but I don't now how we can change with them. Clearly Navision has moved into the "satisfaction now" world. Personally I don;t want to be a part of that, but I also realize that I want to remain an active part of the community. So I have been spending some thinking time taking a look form a different perspective and working out how to help people with out being insulted by them.
I see the solution is more in providing solutions, NOT providing answers. So I will be working more in that direction. I will still be active in the forums, but will concentrate more on WIKI and BLOGs.
Anyway time to catch up and see what I have missed.
I didn't realize it had ever not been this way
I've felt that way for a long time, that is too much of providing answers and not enough providing steps to figure it out for yourself. I know I've failed at doing it a large portion of the time. I feel like every time I even try to do it the reply behind me is just the code written out for the original poster or the step by step instructions to fix the problem. I understand not re-coding / re-inventing the wheel, but... ](*,)
Communities = Help me understand what to do.
Help Desk = Tell me exactly what to do.
At least that's my opinion.
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
This is clearly the trend the society is moving towards.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
Yes which is exactly what I am saying. For a long time Navision was "different". It is now becoming mainstream so to speak.
Pardon me but I’m a newbie here and I didn't get the point. Navision employees will write to their resume that they have worked for a certain company for 15 years but in fact they had just worked for 4 months? Is that what they call resume inflation? That is because they are cheating about the information in their resume.
No you missed the point. resume inflation is common. The issue here is that Navision is different, and many employers and more importantly, customers, do not realize this. Let me use an analogy.
lets say you are an auto mechanic and have 10 years experience working on Mercedes. You could probably do a course and in 3 months you would be a competent BMW mechanic. Even if you wanted to fix Toyota, its not a huge difference and you could swap over pretty quick. If you were a mechanic for 10 years fixing BMW, Mercedes AND Toyota, then the whole 10 years experience would be useful in fixing any of these cars. Lets think of the mechanic as a a C++ programmer wanting to learn C# or an Oracle developer wanting to switch to SQL.
But now lets look at a taxi driver in New York, lets say this driver spent 10 years driving in Manhattan. They would know all the roads and short cuts and traffic issues. BUT if that driver then moved to London, virtually the entire experience is useless. They would have to start to learn all over again. You can't simply say. "I was a taxi driver in New York" so I can now be a taxi driver in London". This is like a SAP consultant moving to Navision. yeah they know how to drive, but once they get behind the wheel they really do not know where to go.
When companies think of Navision as a programming language, they are doomed to failure, and their customers have no hope of a proper installation.
I traded my sanity for a railgun
This is also the mistake of many employers. I took my first NAV position right out of college. I had been programming for roughly 10 years, although certainly not on any professional level. Just high school and college classes and for fun. I was put through the development one course, aka this is how you define a variable and write a loop in C/AL, but not put through the development two course or any functional training. I was expected to be able to implement and support a payables department with that knowledge. As you can imagine, I was pretty worthless.
I traded my sanity for a railgun
This is the way it used to be done, and the way it should be done. I think most people will agree with this. The guy signing the pay check though seems to rather see billable hours at all costs.