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.