Today is the last day of Convergence 2007 EMEA in Copenhagen. And today is where I will be speaking about the Dynamics CRM implementation my company ISS is doing (session: CRM313 Thursday at 14:30). After 3 days of listening to several very borring customer cases, then I would think Microsoft should have asked me to be presenting the Dynamics NAV Core roll-out in ISS. Or maybe the one we made in my previous company GN Store Nord rolling out NAV to 15 countries. For years I have been working with these large international multi-site/multi-country implementations, and with very good results and many happy users.
But yesterday at the Multi-Site International session (NAV212 - Microsoft Dynamics NAV for Multi-site and International Organizations) I basically got my answer to why I would never be selected to present my customer case.
The first reason is that we both in my current and previous jobs have selected the "one database" strategy. That means that are implementing after a "one code in all countries" plan. Having all localizations in one database. Not that we are using the official country localizations and try to put all that into one database. That will basically never work, as most of the localizations done by local Microsoft offices are all done without coordinations with other countries. But we are creating exactly what we need for our company to apply to the local legal requirements and nothing more, whereas the official localizations by Microsoft have the target that they must support all type of businesses in the country. That that means that there are often create a lot of localizations that we do not need in our business.
But this is NOT Microsoft's strategy. Microsoft's official recommendation is that multi-site companies create a Core and then implement this core in separete database for each country. They actually claimed that the TCO (total cost of ownership) would be a lot higher by selecting the other approch. I can easily prove that this is NOT the case!
The other reason for why they would not want me to speak about Dynamics NAV is that Microsoft's official strategy is that all implementations should be done in cooperation with a Dynamics NAV Partner (VAR/NSC). Both in my previous job and my current we had the best intentions about working very close with a "lead partner". But in both cases this proved very quickly not to be possible. At least not if we still wanted to keep full in-house control of the project and costs (keep them low). What we experienced in both cases was that as soon as the initial project was done (Core development - and the majority of the project cost paid) it was very difficult to get the attention and resources we are requesting.
The only way I can get the resources I nedd is currently by using the body-shopping method, and getting individual resources from different partners (or freelancers). Also the issue about knowledge transfers has proven a very big issue, which we would have thought that the international partner we selected whould have had a lot more experience in. At least that was what they claimed when we signed the contract ("we have a proven international implementation model"). I don't know if it was the fact that we wanted to stay in control of everything and did want just to put everything to the partner that made the model not work or what it was!
At the same time I must say that our model of managing everything inhouse (have our own solution management) is not the right model for all multi-site implementation, as it does require that you have number of in-house resources with the experience in running this type of projects.
But clearly our project setup is very far from Microsoft's recommendation and strategy.
So all in all I do understand why they don't want me to present our project. Although all we can show is good results, low TCO and happy end users in many countries.
What do you expect? Microsoft's recommendation and stategy IS the only choice! ("Nothing else beside me.") Even if other companies and/or people can do better and can proof them wrong.
I've been involved in a 'one-database-for-multiple-countries' project (which is probably one of the projects that partner claimed the experience Erik), and we got absolutely no cooperation from Navision, which was not yet MS at that time. In fact the only contribution we got was "that will never work" and we had to solve all the problems ourselves. The single biggest reason why that project was such a success is because the customer took ownership of the implementation, they ran the show with our assistance.
We can argue about whether it is the right business model, but it is the one in place, and I understand completely why they would not support something like that. Even if they'd want to use a one-database model, the license would become very expensive, and they'd have to make all the "NTR's" happy. How will they divide profits?
The key here is that it's the customer who needs to take ownership, and with the partner model currently in place for NAV that is just not going to work.
Yes the response we initially got when we said we would do this in my previous company was the exact same "that will never work". But they actually also claimed that we could not do it because if the license agreement. In fact I had to explain them how their license agreement said that I could do exactly what I wanted. It wasn't before their own legal department had confirmed me, that they believed me!
But you're also right that I have so far only seen this model work where the customer has taken ownership of their project. In my eyes it's not really because of the partner model is wrong, but that the partners are not mature enough for the biggest NAV customers.
In my previous job our NAV group was in fact bigger than any of the Danish NSC's (we had almost 50 certified NAV experts in the department - and no salespeople to mess it up! ). So what could a VAR/NSC actually help us with? Besides providing some extra hands - nothing!
But seriously though, there are not a lot of Erik P. Ernst in this world.
For your strategy to work, you need very good professionals with ample requests from the end users to keep them busy.
Microsoft's method is designed so it doesn't put too much strain on the customer and the partner that provides the service to them.
Hehe, well just here in Denmark I know at least 4 other projects (which I have not been involved in!) who have done the exact same thing.
But you're right the method designed to make a rather easy project for the customer and partner. But I would anytime say that your TCO will be a lot lower with a one-code strategy, if your project is of a certain size.
In US we have NA version, which has all the requirements and some more for 3 counties.
I'm surprised why they don't consolidate countries in europe.
Countries that have very similar gov requirements should be all in one version.
This will lower the merging of different databases.
They have actually done the same in Asia Pacific. The versions convering Thailand, Singapore, the Philippines, Australia and New Zealand actually all have all localizations in the same pack. It's basically only India who are on their own.
I was in this session and heared your question about localisations in one db. Microsoft gue didnt understand you. If ypu are talking about local implemations ypu should say customizations instead od localisations. And customizations should be equal in every db. Such words said men from microsoft in the retail session.
It was not me. I didn't ask any questions in that session, because I did know the answers already.
But I don't really understand what you talk about regarding localizations vs. customizations. When I talk about localizations then I'm talking about changes to the NAV system to make the system live up to local legal requirements and also local business requirements. This is basically what the local Microsoft countries are doing in their country versions, but if you do a global one-database implementation, that's also what we do per country, if we are not using Microsoft's localizations (which in general we are NOT).
Customizations are (for us) all the changes we do cross-country (in our Core - COrporate REquirements). Changes that are made to support OUR BUSINESS and doesn't exists in the local or world wide versions.
Your post is quite interesting to me and I would think that a discussion on this topic would be quite interesting in one of our upcoming Dynamics Partner Advisory Board meetings. The approach that you have outlined is challenging for the majority of customers. However, the gap that you have highlighted (multi-site, multinational deployments) and the need for capable customer / partner resources to address this issue is an obvious bridge that we need to build to do this work at scale.
Would this discussion be of interest to you?
This is always a very interesting discussion and I have taken it quite a few times before, both with Microsoft and many of their Partners. I think that there is really not just "one answer" or one "right way" to the question about what methodology is the best. It all depends on the scope of the implementation and what team the customer is able to build, both internally and externally.
But please contact me if you want to discuss this topic further.
Back in the old days when I was responsible for Localization of Navision though out Central and Eastern Europe, we developed one code base for all countries, and it was no problem at all.
But that was because it was just me driving this, so I would look and see if the "local legal requirement" was really a legal requirement or just laziness on the part of the local people to do their job.
From what I have seen of localized versions these days, is that there is no ONE person in Microsoft that is able to coordinate all the regional requirements. There is too much reliance on local people to set the rules. They just let countries go mad and put anything they want into the standard.
The ONLY local version of Navision I know of that was done properly was the NA version.
It would be far better for all concerned, if the product could be more consistent across countries. If nothing else, it would make for much faster product releases.
For those localizations that are used by less than 20% of implementations, those customizations should be released as an Add-On, and not as part of the local code.
And India should move either to W1 or NA, because what they have now is the major reason that sales and implementations in India are falling apart.
One other thing, is that "back in the good ole days" most NTRs were actually independently owned companies. Those companies invested heavily in localization of the Navision product for their region. Since we were handling 7 or so countries, it made good economic sense to integrate the localizations. But it also meant it was possible for a client to buy in one country and us in another. Thus the NTRs wanted their protection, so they added a lot of garbage to their localizations, just so they could tell clients that they had to buy the local version for legal reasons, and that if you bought say the W1 version, then you would be sent to a siberian slat mine for 50 years as punishment by the local tax authorities.
Local authorities just need their reports, so that was all just BS to try to keep revenue int he country that did the localization.
But now its all just one company, so Microsoft even fromt he economical point of maintaining less versions need to see that a merged product is a good idea.
I think you are very right. As I see it then Microsoft sure is on the right track. If we look at the Asian countries then they have made "one version" with all localizations integrated.
I presented the NAV 212 session Multi-site and International Organizations (MIO). I would like to take this opportunity to clarify some statements made here in this forum.
First, let me state that I have never been approached by Erik P. Ernst around his feedback to this topic nor around any opportunity for him to speak at any Convergence.
Second, we as Microsoft do understand the various deployment model for Microsoft Dynamics NAV supporting MIOs. As I stated in the presentation and as noted here in the forum, we have a recommended strategy and we do not recommend consolidating various localizations into one database. As I stated in the presentation, we know that some partners and customers have followed this approach.
Third, our global localization and development department are consolidating localizations where this makes sense. Still, we release the localizations in seperate databases as our strategy. This was also the case in the past.
You are welcome to contact me directly as I will not post on this forum.