In August 2006 after I just started in my job at ISS I wrote about my worries about Finding the right model for our global Microsoft Dynamics NAV solution. Since then 2.5 years has gone by, so I thought it was on time to write a little about what has happened since then.
The model we decided on was "one global database", with the option of local databases. As I wrote back then, then Thailand was our pilot country with planed go-live in January 2007. And it didn't go better than some of you might remember that in the end of December 2006 there was a big earthquake in Taiwan, which interrupted most of the internet traffic to and from Asia for the first weeks of January 2007. So the only option we had was to get a backup from our hosting center in Linz, Austria downloaded and then setting up a local SQL Server on a desktop pc (the only pc that was available with such a short notice). But when the New Year holidays were over, we went live as planned. After three months, as the traffic was normal again, we moved the Thailand companies to our server in Austria.
The other countries we were setting up in 2007 were the Philippines, Mexico and India. They all went live on our global database.
The only country where we had to setup a local database was Taiwan. Here the connection was simply not good enough. So a local SQL Server was setup here.
We had planned more implementations during 2008, but Taiwan was our last go-live on our Dynamics NAV version 4.0 SP3.
The major issues which we had encounted was that we never got our Reporting Services based BI solution functional. When the ISS bought the solution (before I joined) they where told that it was not possible to create consolidated reports across companies in Navision was to use a data warehouse (DW) solution. And as each country in ISS has many local legal units (individual companies in NAV), which are reported to the ISS global head office in a different way (often 2-3 legal enties in one reporting unit) as well as consolidated reports for the country, then this was a very important issue.
But the reports never got to work. Not even something as simple as a balance sheet report. And not even a change to a partner specialized in reporting services were able to get it to work. And while the new partner had been using almost 2-3 months to get the balance report right, then one of our very good NAV developers were able to create a consolidated balance sheet report in Navision in 2-3 weeks.
So our Data Warehouse and Reporting Services solution was scrapped and all the reports were done in Dynamics NAV. And they were not slower, which had also been another argument for the DW/reporting services based solution. On top of that now everything is based on real-time data, where our DW solution was only updated one time per day.
When we started the project our strategy was to use one global implementation partner (Tectura). The argument, as they were active in most of the countries where we were implement, which ment that we could use local implementation teams - at local costs. A very important factor, as the daily rates for consultants in Denmark is almost the same as what we would be paying for 2 weeks in some of the low cost countries in Asia. But a factor which had not been taken into the calculations was that although they called them self a global company, then they did not have any structured system of doing knowledge transfer between the teams in Copenhagen and in the local countries. And on top of that we also under estimated the importance of the knowledge of ISS' own business processes and accounting policies. Our solution is basically very simple, so we didn't really pay enough attention to this.
The first version of our solution was developed some very good developers from Tectura in Denmark. Then the plan was that the continued development/maintenance should done by Navision developers in Asia. But that wasn't that easy either. The company in Denmark were not able to find a very good solution in how to handle this, even though it was their own sister company. So the only way we could get it to work, was that we basically had two different partners. One in Denmark and one in Malaysia/Singapore. But we were very happy with the developers in Malaysia, and when we heard that the senior developer was considering a job offer from a different company, we decided to hire him. So now we have two developers located in the ISS office in Kuala Lumpur in Malaysia.
In Q3 2008 we started the development of the next version, which will be based on Dynamics NAV 5.0 SP1. This version 2.0 of our Global Core we are going to change many things. The most important module of our solution (the job module) gotten improved so much that it's now actually a useable module, which means that a lot of our customizations can be removed and replaced by standard functionality. Also have we learned that it's not a very good idea to use local Microsoft localizations directly. Simply because they on the long term will limit you more than they help you. We did that both in Thailand and India. So in the new version a completely new solution is being designed to include a truly international vat/sales tax and withholding tax module (I will write more about that in a later blog post).
The ISS companies in Japan and Polan is already on the NAV 5.0 based version - but only with the G/L, A/R and A/P modules. The remaing modules will be ready here in Q1 2009. And then the roll-out will start in 2-4 additional countries in 2009.
Our initial solution was created by a team from our original vendor and the IT staff from ISS. And then there was workshops with some of the accounting managers from some of the ISS companies which were using Navision already in local solutions (about 15 countries). Based on this the vendor created a specification, which basically was a list of required changes to Navision. This is a very normal way to do such a solution. But it's not the right way! The problem basically was that all the asumptions about how the business at ISS worked, how ISS' business processes worked, was not documented. So we got what we asked for. But we basically didn't know how this was fitting to what we really needed.
So my main recommendation to everyone starting a big implemenation as us is, always start with describing all your company's business processes in detail. It takes time, but it's invaluable. And when we finally got this done (by the end of 2007) we were really able to get a clear picture of what we needed to change to get it to fit to the "real" requirements we had. Additionally if we had this document from the beginning, then the knowledge transfer to the local implementations teams would not have been that complex.
In connection to the above, then don't under estimated the time it takes to do knowledge transfer. Knowledge about how your company works is just as important as knowledge about how Navision works. And this knowledge should not be split on two different persons who don't talk the same language (ex. one talks business and one talks Navision).
I know this is an old entry, but did any of you ever consider using a different collation for each company, like I suggest here: mibuso.com/.../viewtopic.php
Thank you. And nice to hear from you again!
Yes if they are really serious about NAV, then they should understand how important Unicode actually is for some companies!
This is a great Blog post Erik.
You really have covered the points well.
Now if we could just get Microsoft to understand why Unicode is so important.
Nice to hear a opinion from a customer side. It has been 4 years since my point of view isn’t in that side. :-)
Documenting business needs and business process from all stakeholders it’s quite vital for rollouts being a success. I have already been in several rollouts and it some of them it could be problematic then NAV business model doesn’t fit’s local business local. Some of this occurs because not all countries all involved in requirements and in other projects there is the rule to uniform business model.
Most Kernel solutions that I know fits about 80 % to 95 % to local subsidiary. Remaining requirements most of the time are specific to country, so I think quite important to previous know local business process before taking final implementation. In some core implementations there is the possibility of subsidiary to make change request so project fulfill 100% of requirements.
A good core knowledge transfer depends most of the time of good key users. Some users are so committed to a project that at the end of the project are ready to support local implementation.
Dynamics NAV Partner should help transfer knowledge and most vital part it showing that rollout project fits their business model, even doing some local modifications in business model.
Thanks for your comments, they are very appriciated. When I write my blog posts, then it's always nice to hear that they have started some thoughts with the readers.
After I have read your and Peters comments I have really been rethinking "my project". The problem I have there is that I was really not part of the initial phase of it, as I was not yet hired. But thinking back on how I got it referred, then I think that our projects major pitfall was that everyone told me "it's really so simple!". And in fact it is, at least seen from a technical point of view. Nothing near as complex a solution as the one I was used to in my old job, where we had a very complex international SCM solution. The ISS solution is "only" a Job Contract/Billing System! They where also looking at each individual ISS company as small independent implementations (which they are).
I think that "fact" made everyone, including our internal IT staff and our partner, think that they didn't have to do a full scale BPA.
So what is the conclussion? Never underestimate the importance of knowing your company's business processes. Never start the project together with a solution partner without having someone on your internal team who really both understands your business and the system you're about to implement.
As to your last question about the international projects, then I would love to discuss that with you off topic (I also plan on writting a blog post, but later). If you send me your MSN address to me, then we can talk about it there.
For the last 2 years I happen to be such an in-house Navision PM at my country`s subsidiary of large international company - after 5 years of working at several Navision Partners and little freelancing. (Altogether I have been working first as programmer, then systems analyst and development PM for more than 25 years). I can only agree to you, that in such situation there must be someone with NAV background on the client side, too - client`s CEO, CFO, key users etc can define their BP & FRD adequately only in standalone (and not-so-big?) companies.
Why Partners don`t request reliable BPA? What I`ve seen is approx the following - in preproject phase Partner sends a team of 2-3 analysts to Client, they inquire key users & managers and after that THEY write the FRD, with nice Use Case diagrams and rather unconcrete textual blablabla, some are smart enough to add MS Project colorful timeline on A1 sheets... Client is happy to get this 100-more page "document", and why not, he has paid big bucks for this...
It`s right not only for NAV projects, most program development projects follow the same scenario.
But... I`m ready to eat my red baseball cap seen in my avatar, IF the client really UNDERSTANDS at least 10% of all this crap - have you tried to show to an accountant - or Board of Directors:) - a Swim-lane diagram of preparing, say, a Purchase Order, showing all consecutive actions, approvals, what-if`s and so on? Programmer understands it, so do analysts, but accountant? There should come in someone with both NAV and system development background.
If client company is small/medium with more or less standart BPs, that will do - Partner will implement system as described in "document", actually, simply gives to client standart (localised) version with few, if any, customizations.
Peter above wrote that serious analysis takes time and money, but I agree that THIS should be the most important part in complex implementation project, and in successful projects it really takes most of the time, as skilled programmers can code almost anything rather quickly, IF they have adequate FRD to follow.
The problem is that rather few clients -even big and international companies- understand the reasons of long analysis phase and consequences of not doing it properly.They suppose Partner is specially extending time - as consultants are paid per hour...
Erik, actually I haven`t said a word about your main theme - big international project as yours. How did you manage to get together 15 countries with different legal requirements? I have something similar - but in 3-level hierarchy, that is, country, then regional, then main HQ. Actually only 1/4 of all workload is for country level, which can be done in country-localized version, but the same data after some slicing & dicing must fit both upper levels, maintaining compatibility with conflicting legislation, that takes other 3/4ths.
We don`t have one global database as you, even there isn't NAV everywhere - maybe in my variant it's easier, but I really don't know what I could do if I should have to put it all together in one DB :(
To end up this long comment I can comfort myself with 2 things:
First, I'm a PM at lower level of hierarchy, thus not (yet) being fully responsible for the whole system, as you are,
and second :)
I'm not (yet :)) ) a MVP, as you are, so I still can afford not to know and solve everything:)
Thanks Erik for sharing your experience - this is in regard not only to this post, but also all you have done in 14 years of DUG!
That everything needs to be documented, including the business processes, should be clear to everyone who have done bigger ERP projects (yes even smaller). When I started my job there, I was their first employee with a NAV back ground. The other employee in that department was a project manager with no real knowledge of ERP implementations, except that he had been a part of another ERP implemenation. My first question was actually "Can I see the business process analysis?".
So what I really don't understand is, why didn't the partner request that such a document was created? Were they scared that they would be turned down, or did they just think that sending in a few senior NAV programmers/consultants could make it up for it?
You make two of the most valuable comments in your post.
Firstly, the EXISTING business processes must be documented clearly and agreed to by all concerned stakeholders PRIOR to deciding how/when/where/why to do anything at all. Most companies don't realise just how much of what they do is contained in various people's heads and in most cases is not 'shared knowledge'. Once this has been done, you can THEN start looking at what you would truly LIKE to do and use the differences to determine the configuration of Navision. Of course, both of these additional items should ALSO be well documented and agreed. And ... this all takes precious time and resources.
And second, knowledge transfer is something that is all too often underestimated and planned very poorly. Too many times do you see companies taking the approach that they will "train super-users who will then train everyone else". Almost invariably never happens. Plus, on the business side, you need to have someone, or preferably a group of someone's who TRULY understand the business processes OR are in a position to find and interrogate those people who do understand and can explain and/or demonstrate. In any case, it should be up to an individual or a core group to document ALL the information to ensure that it is standardised and consistent.
The other thing that cannot be underestimated from the client side is a full-time resource whose job it is to do nothing else but look after the project. We all know that partner project managers are often shared amongst various client projects, but this simply doesn't work in-house for the client. They must take pro-active control of the project and ensure that both internally and externally, it is delivering what it should be.
And communicate, communicate, communicate.
Nice post Erik - interesting insight into lessons actually learned!