By Nick Prevett, Sr. NAV Project Manager This blog post is designed to outline and specify to customers why InterDyn BMI advises against a Microsoft Dynamics NAV solution strategy based on a single Microsoft Dynamics NAV database modified to contain all localized versions required. Microsoft advises against a centralized single database solution containing multiple country functionality. There are basically two ways of deploying a solution in a multi-site and international deployment scenario: Distributed deployment is when there is a separate database for each site. This means, that each site will connect to their individual database for performing their business. Each database will include the “core” plus add-ons and the local customizations – if any. The database can be located at the site or it can be hosted at the parent company (or at a third party). If hosted, the site would then typically connect via Web Client, Windows Client, or CITRIX. Each database will have their separate license that permit the site to run the licensed functionality and the number of users. Microsoft Dynamics NAV supports this scenario. Customers would be international organizations with sites in multiple countries. Centralized deployment is when there is one, central database that all the sites connect to, e.g. via Web Client, Windows Client, or CITRIX. The sites will connect to their separate “Company” in the database to perform their business. The database will include the “core” plus add-ons and customizations. The database will have one license that permits the sites to run the licensed functionality and a total number of users. Microsoft Dynamics NAV supports this scenario – if the database is a standard country version (incl. localizations and local language) or standard W1 version (no localizations). Customers would be multi-site but domestic organizations where the sites are located in the same country. Important If the multi-site and international organization requires multiple and complex local functionality to be available in one centralized database – Microsoft Dynamics NAV does not support this. For example, the organization wants a Danish license and then includes all Norwegian and Swedish localization for their sites. The TCO will not improve in this scenario compared to the distributed scenario for the following reasons: The savings would be marginal. Organization would need one server instead of multiple servers, yet multiple connections. Organization would have one Microsoft Dynamics NAV license with the total number of (concurrent) users that can be shared among the sites. Potential user discounts on the individual licenses would make this saving marginal. The costs could be substantial. Development and maintenance costs would be higher, especially considering deployment of hot-fixes; service packs (e.g. legal updates) and upgrades (new versions). The solution would be very complex and it would be difficult for the customer to find another partner that could take over the support. It will also be problematic if not impossible to run local add-ons. Impact on project roll-out In general, a project will be more expensive to accomplish due to the higher solution complexity and because there are more sequential processes in a single Microsoft Dynamics NAV database solution than in a solution running on multiple logical Microsoft Dynamics NAV servers. Some of the key areas are mentioned below and detailed in the following sections. Increased development costs (please refer to the application issues section) Increased dependencies on individuals – it is almost impossible to change partners due to the increased complexity in a single database solution Restrictions to parallel country implementations – Much costlier (if possible at all) to run country roll-outs in parallel due to local GAAP resolving Licensing Let’s take the example of a customer that has favored a single Microsoft Dynamics NAV database solution in their original conceptual setup in order to optimize concurrent users across time zones. This setup requires that several procedures be followed in order not to violate Microsoft license terms: The company will need to purchase the right to use the local functionality in a local license before it can be extracted. Extracted objects have to be manually renumbered and modified to work in another number series before it can be imported into a single database solution. It cannot be automatically imported but has to be merged into the central database solution. The local licenses purchased to gain access to this functionality cannot be utilized in the central database solution. These comments are based on the example of a fictitious customer whose strategy is to do central development of one solution for several countries. We have walked through the concept of managing change earlier in this document. We would now like to pinpoint some of the issues and risks that we see in the way that the management of the project and the code change is designed Before we start describing the possibilities of managing code only centrally, versus centrally and localize locally, we need to emphasize that the concept of code management really has nothing to do with the discussion of central and hosted servers. A central server is an infrastructure discussion and there is no good argument for why a central server requires or is best served by a central solution, or why a local server requires or is best served by local development. This is a common unfortunate misunderstanding. Several local solutions can be managed well, and a central solution can be completely unmanaged as well. We would however emphasize that having no CORE strategy at all should always be avoided. But there are two ways to manage many countries with a solution: 1. Central Solution: The solution is developed centrally only. 2. CORE developed, localized: The CORE functionality is developed centrally, while countries pass through a formalized localization process with strict change control. Option 1 could be our preferred choice for a customer who for example has a number of small sales offices in 2-3 countries only. Option 2 is the preferred solution for any roll-out that would include more countries or have significant business operations (for example manufacturing and distribution) around the world. So it must be emphasized that customers need to separate the discussion of managing central servers versus managing central solutions. Customers do not serve their own interests when they blend these topics in the discussion in the future. When we think of a software development project, we try to have an eye and a consideration for the maintenance part. In that discussion we continually try to build an estimate of what it would cost to maintain this solution with the customer. We work on what we call the maintenance ratio and try to address the issue of how many % of the total software costs is spent on maintenance. Our estimates and experience on a central strategy with no localization is that there is currently no evidence that maintenance ratios are lower on central solutions – in fact it can often be higher. We believe that there are benefits to a central solution but we also think that the challenges very often outweigh the benefits. The challenges are listed below: Challenges With one solution, you will see the complexity increase with: The number of countries due to the fact that individual country requirements have to be assessed, and The extensiveness of use in the individual countries. The maintenance curve is not straight. It takes an exponential pattern, so that many countries and many business requirements will have a huge impact on the maintenance budget compared to a “Core development and roll-out” type of project. We have pinpointed areas where a central development can become problematic compared to a “CORE developed, localized” process: The size of the local changes are huge worldwide. With a CORE development and localization process, there is local functionality within the standard Microsoft Dynamics NAV country release which can be used. A central team would have to embed the local requirements into the central CORE solution by adding new functionality that satisfies the local departments. The example below provides information that should help you not to underestimate this process: Example: Based on our experience and the current figures, we can say that the Danish market brings 2-3% modification to a central solution; in Switzerland it is 25 – 30%. Poland it is in the neighborhood of 15-20%, Italy around 15%, Spain 25%, UK around 17%. A few of these localizations can be discarded as not required for an international company, but around 80% cannot. If you merge it in through the central development process you are so to speak “reinventing the wheel”. This code has already been made and there’s little actual value to a CORE solution in merging this. Instead it builds a huge issue when you want to upgrade to your next release. To present this in the right perspective we are talking of new and modified objects in a country often exceeding 500-700 objects (except for the Danish solution which only contains very few changes due to historical reasons). The manual work to overview a single-database merge and to manage application conflicts is substantial. In a single-database solution scenario it is possible that 30% of all objects in the database will consist of modified objects that cannot be upgraded via normal automated procedures. This is due to the fact that all localizations have to be renumbered before they can be modified and merged into a common database. Consequently, upgrades to a new version may exceed half a man year in the single database solution scenario. Some local changes overlap one another One of the areas that we try to avoid is the “change-on-change” aspect when we upgrade a solution. The maximum number of changes that an object can have is in our case 3 changes: one is worldwide, one is company specific and the last one is local. This works for us because it is manageable when we need to upgrade. A centrally developed solution would not have 3 levels of changes but many more. Around 60-80% of all Microsoft Dynamics NAV local solutions have implemented changes in one of the most complex functions in Microsoft Dynamics NAV. Example: The Post Sales Document function: As a general guideline you could say that if you, for example, have 20 countries where to roll-out your solution– and if you use the pessimistic angle of this, then you have to implement 20*80% = 16 levels of changes. A level of change means increased complexity for the developer and implementer. This is manageable but it will be extremely expensive to manage and the test case for this would be all too complex to consider all the scenarios. The impact is a delayed product roll-out and increased expenses compared to a “Core Developed, Localized” scenario. Some of these changes are incompatible with each other Example: Let’s give a very simple example: the address formats are different in UK compared to other countries. This requires that you figure out how you can have forms including county codes in UK and not in other countries. Other example, Poland has an extremely restrictive credit memo process which would be useless in a Western European country. This process is however required in Poland due to local law. Spain has Cartera embedded in the Sales Process which would never be required in Denmark. And we could go on with other similar examples. The top level most obvious challenges are: a) Management of future Microsoft Dynamics NAV upgrades: Building a central solution is not a problem the first time – however a central solution has an impact on later maintenance and future upgrades to later releases of Microsoft Dynamics NAV. Unfortunately, local requirements tend to be deeply embedded in the standard code so it is no easy job for the development team to handle this. The high code embedment measures are a good example of this problem. The more local changes the development team builds into the central CORE, the further away the CORE moves from a standard Microsoft Dynamics NAV version. This can give problems in updating the CORE with the standard Microsoft Dynamics NAV releases. b) Business focus of the development team: A development team typically works with a CORE solution for one basic reason: To bring in functionality that is specifically needed for their own company and which will give them a competitive position in using the software. If the development team also has to relate to local requirements on top of this CORE development the effect can be that the development team loses perspective of their primary target – slowly the development team changes to a local requirements change management team. While this will work for some with simple business requirements, the problem is that the original priorities for buying the software are lost. c) Time-to-market indicators: The development team is hooked up with the number of countries the solution can be released in, and the more change requests anticipated per country, the longer the countries usually have to wait for a release. A one-day delay of one release to satisfy one country will eventually lead to delays for other countries as well. d) Local look and feel: Local changes are made for a reason and there will be local changes that cannot be embedded perfectly in a global code. This is for example the case for the look and feel of address formats and languages. When users feel that they don’t have “their” solution they can be left somewhat dissatisfied. In order to bring user satisfaction up it is therefore important to introduce other ways of improving user satisfaction. This blog post has demonstrated the reasons why we usually advise customers against a Microsoft Dynamics NAV solution strategy based on a single Microsoft Dynamics NAV database modified to contain all localized versions required. We did that using concrete examples based on real life experience. If you have questions about this information or would like to hear more about it, please contact us . You can also download and save the whitepaper format of this blog.
↧