“The Way To Grow” used to be Navision’s slogan back in the 1990’ies. And that was how the system was sold, the ERP solution for successful and growing SMB’s (small to mid-sized businesses).
Navision started to ship localized versions in the early 1990’ies, so it was a natural choice when these growing companies, expanded into to other countries. Instead of finding another suitable local ERP product, then Navision allowed them to use the same ERP system everywhere, as they used in their own headquarter. Most global implementations started simply by companies requiring their subsidiaries to use the standard, whenever available and possible.
Before you start to think, that this is just another one of my “Navision History Blog Posts”, then let me say that is not! This is really just the intro post towards how to do a global implementation of Dynamics NAV in the age of Dynamics 365 Business Central. If you have already done plenty of global NAV projects, then you may skip the rest of this post, and wait for the next post. Unless you like to know the reason for my conclusions in the next post.
If you have never been involved in a true global implementation, then you may not know why such an implementation is different from most other implementations. Or why a global company would want to go the extra steps.
One of the most typical requirements such an international company may have is common master data. That could be a common chart of account, dimensions or items. Sometimes vendors and even customers are shared between subsidiaries. The reason for the master data is often to be able to get a more unified and cleaner reporting on financial and other data.
Or the company have a set of global administrative and operational processes, and they need their ERP solution to support these. In large corporations the way they do their business, is what makes them successful.
And often, more and more in these cloud times, then they either have their private global cloud or a different way to host it globally. Why have 25 local installations, when you can have one large global? Why pay 25 times for the same work for development etc.?
But NAV doesn’t really support to have all countries in one database, when each localized version has a different database and set of source code.
The most common and quite straight forward way to do it, is to use the localized versions of Dynamics NAV. Every country has their own database and license. Either locally on premise, or centrally on-premise/private cloud.
When the global core NAV functionality is developed, it is often done using the world-wide version (W1) of NAV. The new or changed functionality, will then be merged into the localized databases.
The model doesn’t require too much from the customer to get started. Once the core functionality is designed and developed, then they can leave it to local subsidiaries and NAV partners. They then help the subsidiary implement and maybe customize it further with local requirements. Once live they would often continue to customize it locally, without having to coordinate with HQ or their sister companies. It's their local solution.
Other companies again have centralized global implementation teams, which implements the solution in all the countries. If the roll out takes years and core in the meantime has been upgraded to a never NAV version, then instead of first upgrading existing countries, most often the efforts and money is used on new implementations.
The main issue with the template core is, that although a common template was used at the time of implementing the country, then after a few years, each country can end up having a solution very far from the original. And sometimes nobody wants to prevent a subsidiary to get the changes they need.
Then when an error is found in the core functionality, which is required to be fixed in the all countries, then this will often take individual fixes for each country.
Upgrading to NAV new versions becomes very time-consuming having to be done for each country. Also if the core functionality is changed or new introduced, then releasing this to many different databases takes a lot of time. Just as with a typical classic Navision implementation with lot of customization's. Here we have the same challenges per country.
Larger companies with a higher demand for control of common global processes and corporate reporting/master data requirements, often find the template core too uncontrollable. (Especially if their group finance department comes from the corporate "SAP world", I should add. Have seen a lot of them).
They may also be looking to save time and money by having a just one global database, one license and only one database to upgrade. We call this the One-Database Core Model. This implantation model is often the next step, after a company had already tried the template core model with local implementations in the different countries. The template core is the one recommended by Microsoft, but it does not always fit all companies.
Instead having a separate installation and database in each country, then we only have one database - the core. Or sometimes more correct, just one set of source code to maintain.
The main issue is that you need to handle all the local statutory requirements on a country-by-country basis. That could be anything from simple requirements regarding which data to show on a sales invoice, or more complex changes like special local taxes. Most companies with subsidiaries in almost all continents would typically as a minimum need to support both VAT, (US-)sales tax and withholding tax.
On top of that, then the global core also needs to contain local requirements. Requirements which may not be legal requirements, but are otherwise required to do business. That could be local payment types, banking integration's, national e-invoicing formats or just changes to support special local business processes and user requirements.
Depending on which version of NAV were used, the analysis and development work could take anything from a few days to many months. Using the standard versions of NAV and just “merging” in the standard localized functionality is most often not possible, as it would conflict with other countries changes in the same area. Plus everything is often not required, if already handled by other countries. A trick has been to start use the US version of NAV as the foundation, instead of the W1 version. This way both VAT and US-Sales tax would be supported out of the box. The us sales tax module is so flexible, that it often may be usable in many other countries. And it comes with "build-in" English (US+CA), French (CA) and Spanish (MX) languages.
The One-Database Core Model is most suitable to organizations with either a global IT or group finance department to manage the project centrally. Most project tasks can be outsourced to either a coordinating global partner and/or local partners (i.e. local training / setup can be done locally by local partners). But this depends on the complexity of the core. The local partners are used to work with their local standard, and may find your way to implement it difficult.
Because of the many customization's, both the from the group, the local businesses and local statutory requirements, often in conflicting changes in the same areas of NAV, a one database implementation can easily become very complex. And each new country adds to this complexity. Requiring more and more test and control of each new change.
What would have taken a developer maybe 8 hours to do in a local database/version, now ends up taking 1-2 times more, when you have to make a work-around to only be visible/usable in some countries and not in other.
The result is that upgrading to a new major NAV version again is going to be almost as difficult as starting all over. The complexity and risk of downtime because of the upgrade does that they often are at least some versions behind before they upgrade again. Have seen anything from 3 to 9 years. Some haven’t even left the classic versions.
Besides clean either template or one-database core implementations, then it is also common to have “hybrids”. For the template core model it could be to have multiple countries with similar functionality requirements in the same database.
And for the one-database core, then some countries simply have too complex local statutory requirements. Here it could take too much time and effort to reinvent or merge to the core. Instead these very complex countries are handled, just as if a Template Core were used. But if you can have one database to cover 80-90% of the countries, then you should still be happy. Sometimes one-database cores are also split into regional like EMEA, APAC, NA and SA. This is done to allow for longer maintenance windows.
For a small company with maybe 5-10 countries, then without doubt the template core. But here are many other things to consider. The more changes your core functionality requires in the standard NAV objects, especially when it comes to areas which are also often changed by localization's, the more often you need to change/fix the functionality, the faster you like to be able to upgrade, the more speaks for the one-database core.
If you on the other like to use a fully localized NAV, with all the local functionality (no matter how worthless some of it is to many companies) and local languages, and you would like your subsidiaries to be able change their NAV to that it better suits their business, then the template core may be better.
Template Core Model
One-Database Core Model
Handling local statutory/legal requirements.
Easy – using localized NAV.
Challenging - Country-by-country analysis.
Initial build – beta
May be relatively easy.
Complex, time consuming per country.
Level of control of code
Low. Easy to customize each version.
How are NAV upgrades or core changes applied?
Must be done and tested for each and every database/country.
Only once, but more complex/higher risk. Must take all countries into consideration.
Licensing. One license required per database. Users, add-ons and objects per license.
One license per country.
One global license. Sometimes larger companies do require more databases, i.e. if +1000 users.
Generally said, then the one-database core does require a lot more, so typically only very large projects. I have seen it used from installations with 15-20+ countries and 1000+ global users. And if that is not your goal, then this is not the right model. Does also require a quite large project team to run it.
The same level of centralized control can also be applied to a template core implementation. Which then would require the same or bigger central team, if still allowing local customization's.
And that's really the key. Any larger 15-20+ country central core projects will require a central team to handle everything from support, training, installation, implementing, testing and releases and everything else required by any new NAV project. Just again and and again for each country. Even if a lot of the processes and work can be outsourced to partners and freelancers, then companies should always take the lead. Keep the key project knowledge in-house whenever possible.
Since Dynamics NAV 2015 and the availability of the “build-in” upgrade tools, including the PowerShell CmdLets to support source code upgrade, it has become easier. Events in Dynamics NAV 2016 made it a little easier to avoid code changes. The first versions had very few standard event publishers, but each version has gotten a lot more.
We have also gotten access to an invaluable Test Toolkit, allowing to perform more than 15000 automated functional tests. Especially important in global implementations.
With the release of NAV 2017 we got Extensions version 1. Although they were very useful in a global implementation and could handle a lot of the challenges with different especially visual changes to i.e. pages, translations etc., then they were still very limited in functionality.
We are on the right track, just as handling customization's and upgrades for all other NAV implementations, then international implementations benefit from the same improvements. The big game changer didn’t come until the release of Dynamics NAV 2018. Here we got Extensions version 2 and the Common Data Services, and a lot more goodies.
But this post has already gotten far too long. I'm sure not a lot of you have followed along all the way.
How Dynamics 365 Business Central may be going to change almost everything for global NAV implementations, will have to be the subject of my next and second blog post about international NAV implementations. The last and third post will round it up with more practical tips on how to start a global NAV project with Business Central.
interesting and informative - look forward to the next 2.