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.
I was responsible for the localisation of the Belgian version in the "old days" (1997-2003). On the other hand I have been involved in several international projects as well: you get the questions mentioned here everytime. Personally I think making a mix (or the regional approach if you like) is the solution to go for.
Some countries require more localisations than others, that is true. To give an example for Europe: the finance area in NAV is oriented towards Anglosaksian bookkeeping (England, US, Australia, but also Denmark, ...). In this kind of bookkeeping system there is a lot of "freedom" so to speak. This is quite opposite to so called "Roman" bookkeeping (that starts with Belgium and down to the south of Europe: France, Italy, Spain). In this kind of bookkeepping system the left hand doesn't trust the right hand .. if you know what I mean. Hence a lot of extra controls must be build in..
Like David Singleton mentions: no one is on top of it. The process has been out of control (for several reasons, politics is just one of them).
That said, it obvious that there is the given situation today and it will be tough to get arround it.
One element of the orginal discussion is not mentioned: Dynamics AX. Dynamicx AX is THE reason for Microsoft to leave NAV like it is/was for several years. Microsoft does not want to mess up their Marketing. They don't want to make the gap between the two products smaller ... Thats why you, Erik, probably had no chance of explaining your case...
I have been involved in several projects with a kernel development and international rol-out. And all with a different approach in how to handle the local requirements. For both ways there are pro's and contra's. At the moment I am assisting a company with 8 subsidiaries over the world. They have choosen Erik's model. But they made a mess off it. Not because the model is right or wrong, but because they didn't know what they are doing. And that's the most important thing when 'choosing' a model.
Personally I agree with David: it would be great if MS minimizes local functionality and merges several countries into 1 release, like in NA and Australasian.
And it shouldn't be too hard to do that. Different legal functionality could be triggered by a setup or license trigger. Maybe MS can make a start with it now 6.0 has been postponed?!
So Niels, I know you don't answer on the forum, but let me know if I can be of any help with this.
Ralph, that's a good method. The only issue is that even if you only select 10% of the localizations done, then they would still end up with conflicts..
I raised this question at the Microsoft Convergence last week about Microsofts opinion about the centralisation of localisations in a truelly International Database. I still consider it is a good investment for them to select only the true legal localisations and combine them in one Database. Because we have also done it ourselves for UK, Germany, Sweden, Portugal, Spain,BeNeLux and Italy and we selected only 10% of all localisations to be crucial for the local adaptation.
That's exactly what I mean. A lot of these localizations are really "just a bunch of bugfull unneeded hacks" (to quote you). And that's why a company (like mine) rather easy can create their own "global version" which support all "the real stuff".