27 Jul Master Data Standardization in a Global Company using Microsoft Dynamics NAV
Steps towards master data consistency in an international organization based on the example of inventory master data standardization
The tool used for master data management which was described in another article is only a part of the whole process which leads towards implementation and the maintenance of data consistency. Before the tool is used, it is necessary to adopt policy for data numbering and cleansing. After the implementation of Master Data Management System for Microsoft Dynamics NAV is completed, a separate process has to be performed to apply any numbering changes.
Four steps to implement and maintain consistent master data based on item card.
Implementing an item numbering standard
It is obvious that the number is a Microsoft Dynamics NAV parameter that is used for unique item identification. Therefore, item consistency is a perquisite to achieve item data consistency within the whole organization. The definition of rules for creating numbers which will be assigned to items is a prerequisite for master data standardization which has to precede the standardization process. With transparent rules implemented, employees are able to find a specific item in a database based on its number. The process has been shown on the picture below:
Sample item numbering standard mandatory in the entire group of companies
The structure of numbers
When building the numbering structure, it is necessary to apply a method which will ensure that all existing and potential items can be identified with numbers. For this purpose, it is recommended to divide the number into sections, however this implies some limitation and disciple in numbering. It is worth considering whether the number of characters in the project section is sufficient to be used for all projects (taking into account all potential ones). The limit of 20 characters has been used for NAV for a long time and it is not likely to change. With this numbering method, the user can limit the quantity of number series used, which means the manual number assignment is active which may result in errors. To prevent errors, number validation procedure should be developed. Finally, it should be considered what exceptions are possible and how they can be managed.
Where to find information about products (items) – in the technical department, in the headquarters or in the local production department?
A unit responsible for assigning item numbers is usually the technical department. In the case of international companies, the entire procedure is supervised by the technical department in the headquarters. However, if multiple items are managed in a company, individual subsidiaries may be their sole or major producers, which makes them product experts. A unified numbering standard used within the entire group will ensure that detailed enquiries concerning items are forwarded to a respective subsidiary based on item number tracking. Knowing an item number, e.g. its subtype, it is easier to identify in which subsidiary it is stored.
Compliance with item numbering standards within Master Data Management System
The possibility of creating and modifying item information in one single subsidiary within the entire group of companies solves the problem with multiple item numbers faced by many global companies. As each subsidiary creates separate item cards in their local databases various numbers are assigned to the same item.
In case of one of our customers, very effective item numbering procedures were already in place before implementing Master Data Management System for Microsoft Dynamics NAV. These established standards were maintained within each subsidiary even after the MDMS solution was implemented. Data cleansing was of importance, too. The group was constantly expanding by acquiring new companies which became their subsidiaries. As a result, there were more and more units and each of them used their own item numbering standards, different from the ones enforced at the headquarters. After deploying MDMS, they had no choice but to adopt the same numbering standards as the ones used by the head office.
During project works, a special mechanism within MDMS was developed to support Microsoft Dynamics NAV users in proper item numbering. The tool includes documents pinpointing with segments of the item number corresponding to its individual properties.
Data cleansing
As you may know, data migration including data cleansing is always a very time-consuming and disliked process. Our experience in Microsoft Dynamics NAV (Navision) implementations shows that users experience very hard time trying to manage all data migration and cleansing-related tasks. Substantial user’s involvement and efforts are needed to complete the tedious work which is hard to automate. The best way to get it done is to start data cleansing as soon as possible.
Data cleansing is a continuous process
It sometimes happens that after the system is put into operation in a selected subsidiary, we identify errors which were made during data migration or cleansing, for example incorrect item numbers which are inconsistent with the company’s policy. If so, it is necessary to rename the inventory (see the post about renaming inventory). Data cleansing is carried out and completed before Microsoft Dynamics NAV go-live only in a purely theoretical sense. As all errors which were not detected during data migration or system start-up need to be corrected, in practice data cleansing is continued even after the system go-live. It may also happen that the amount of data is so large that its in-depth cleansing before system go-live is impossible. Therefore, it is automatically continued once the system is up and running.
Subsidiaries carry out data cleansing on their own long before Microsoft Dynamics NAV Implementation
However, there is the other side of the coin. If a group, consolidated ERP solution has been implemented in a number of subsidiaries, the information about this is communicated throughout the entire organization in an informal and unforced manner. In the post titled Avoid local problems and promote the project with effective internal PR activities about the benefits of project work and reduction of the number of local problems, one of my colleagues has described the company’s internal policy and PR activities used by one of our international customers, which should be initiated and managed by the headquarters.
No doubt, implementing a global solution in a large, well-developed company is such an enormous change that the employees decide to exchange information about the roll-out, prospective problems and challenges on their own. They may also bring up the issue related to new inventory numbering or master data management system for Microsoft Dynamics NAV. As a result, when they system is implemented in subsequent subsidiaries, they are often mentally prepared for the roll-out They may be well aware that a special method for defining item numbers is used and they know how to put it into practice. What’s more, all new items have been created correctly by the subsidiaries since the introduction of specific numbering standards in the entire organization. Even though legacy items stored in these subsidiaries before data cleansing still have numbers that are inconsistent with the company’s numbering rules, large part of them will be cleansed when the new system is run.
Informal pressures from subsidiaries
Another reason behind this bottom-up initiative undertaken by a subsidiary is the fact that many other subsidiaries in the group are already using this standardized inventory numbering policy. Since a few major business partners communicate with each other using the same “language”, the subsidiaries start to change their numbering policy whether they want it or not, just to streamline communication with other subsidiaries in the group.
The more subsidiaries work on standardized Microsoft Dynamics NAV, the faster the future roll-outs
All in all, the conclusion is that the more subsidiaries in the group work on the standardized ERP system, the greater the awareness of subsequent subsidiaries. Data cleansing is probably the most time-consuming and challenging process in each rollout. No doubt, it takes a lot of user involvement to complete it successfully. If the employees of a given subsidiary start data cleansing on their own before the roll-out and they are aware of how important it is, we can say that the vast majority of cleansing-related work is completed before the roll-out.
Obviously, it is not the only factor that contributes to reducing the average costs of implementing the standardized Microsoft Dynamics NAV in the global company. To learn more about the issues discussed above, please read “Advantages of working with one global team of Microsoft Dynamics NAV consultants”.
Tool for Master Data Management
The implementation of the master data management tool we offer is one of the steps towards implementing and maintaining the consistency of a data in an international organization. The tool has been designed to manage master data, and its implementation is based on the assumption that data has been standardized and cleansed. Due to data standardization, this tool eliminates inconsistencies in the process of adding items into a central database or local databases. However, the purpose of the tool is not to enforce master data consistency, if this data has not been standardized and cleared before.
Changing item numbers in international companies
The problem of item renaming does not concern all ERP systems. Changes in primary keys of database records can affect different systems in different ways. For instance, changing an item number in Microsoft Dynamics NAV (Navision) will automatically enforce changes in many other item-related areas such as item ledger entries, document lines and production BOMs. Thus, the operation is very time-consuming and can cause database overloads. When we change the number of the same item in multiple databases simultaneously and companies working on these databases carry out transactions with each other it may turn out that one of these companies (transaction parties) had already gone through the renaming process while the others are still using the “old” number.
In multi-branch / international companies inventory renaming may be required after implementing Master Data Management System. The diagram illustrates the steps that an international company must take to ensure the complete consistency of item-related data in all subsidiaries.
The first step which involves creating the procedure was discussed in the post: How to standardize item numbering in global companies? The challenges related to data cleansing were discussed in the post: Facing data migration and data cleansing challenges during Microsoft Dynamics NAV implementation carried out in global company. More detailed information about Master Data Management System (MDMS) can be found on our website. The item renaming procedure applies to situations in which a mistake is made while working or cleansing data and when items with incorrect numbers can be found in the MDMS central database.
Creation of duplicates during inventory renaming
If item cards used by the group of companies are stored in the MDMS central database, for renaming, it is necessary to send relevant information to all local databases. When subsidiaries start to exchange items, item data should be already updated.
The number is the only parameter that uniquely identifies items in the Microsoft Dynamics NAV. If the item number was changed only in the MDMS central database, after a while a new item would be created in the local databases while the “old” one would still exists. There would be two item cards in the local databases with different numbers related to the same product.
How to avoid duplicates in the local databases?
To avoid the problem discussed above, relevant information is sent to the local databases immediately after the renaming of the item in the MDMS central database. Based on that, the “old” item number is blocked throughout the day and then at night inventory renaming takes place. At this point, the item can be unblocked again.
The best method for inventory renaming is implementing the change in the MDMS central database, first and then sending the relevant information to all local databases overnight.
The optimal way to rename the items in multiple databases
When is the right time to rename the inventory?
Choosing the right time to carry out the operation is of paramount importance. The process of item renaming can be a heavy load for the local databases and thus, the use of Microsoft Dynamics NAV during this operation is not recommended. The procedure may be hindered if subsidiaries are located on different continents – it is more difficult to choose the right time to initiate the procedure. Still, our experience shows that this approach works best even for such scenarios.
Master Data Management System in the Microsoft Dynamics NAV group architecture
Master Data Management System plays an important role in projects which IT.integro delivers internationally as a tool which supplements the standard functionality of Microsoft Dynamics NAV in the scope of master data synchronization.
The simplified Microsoft Dynamics NAV architecture which is used in a multinational company
Generally, Microsoft Dynamics NAV used by a multi-subsidiary company is installed on multiple databases (local databases), within which many companies can be created. NAV Group Projects Methodology supports the implementation of a uniform setup and data standard in all databases. With this setup, financial reporting and consolidation (OLAP cube) which is based on data retrieved from local Microsoft Dynamics NAV instances is much easier. In order to maintain data consistency in this architecture, the central data base is required, within which data cards (such as item data, customer cards, prices lists, production BOMs) will be created and modified for standardization purposes. The Master Data Management System architecture shown above plays a critical role, because it supports the process of creating, modifying master data and subscribing it to databases.
The use of Master Data Management System for Microsoft Dynamics NAV installed on various servers
Due to the insufficient quality of Internet connections between remote locations, it is generally not possible to run all Microsoft Dynamics NAV instances on one server. Therefore, for such locations as Brazil, India, China or Saudi Arabia, specific servers are deployed. Obviously, only one central database should be used to ensure that it is a “reliable source of master data within the group”; for this reason such a database is deployed only on one server. The Strategy Phase of the NAV Group Projects Methodology provides answers to many questions on the group project, by specifying for example where the central data base should be located. Local databases can be subscribed to the central database within the same server or from other servers as shown in the diagram below:
Servers and databases in a quite typical architecture in a company using Microsoft Dynamics NAV on many continents.
We are often inquired on how data synchronization is performed if such an architecture is implemented. In this case, the transportation layer tool we recommend reveals its benefits. This transportation layer is based on files stored in a specific location in a network folder. As files are used instead of web services, the physical location of the subscriber’s database is of no importance. The access to a central database is based on the permissions for accessing the network location. For more information, please see the video on Master Data Management System. The video describes one of the main solution concepts which is Receiver.
The Project of Master Data Standardization
There is a tendency to treat the Master Data Management System module as a magic wand which is used to sort out inconsistent data stored in various Microsoft Dynamics NAV companies and databases and to prevent inconsistency drawbacks. However, this approach results from the misconception of how the module works. The module enables only the synchronization of data which was previously cleansed and standardized (as described above). It is just an element of the change process which is initiated when an organization embarks on data restructuring and management. Some customers however go beyond the objective of data synchronization, intending to implement complete master data management. For such customers, IT.integro recommends a separate project. The most important steps of such a project involve:
- Delegating a customer’s team for master data management.
- Master data identification (items, customers, vendors, pricelist, BOMs, etc.).
- The analysis of maser data-related processes and functionality. The premise is that MDMS is a generic module, a backbone of the solution the Partner should use to create business logics which supports the customer’s processes. The master data-related processes can vary substantially depending on the customer.
- Support for cleansed data migration to a central data base.
- MDMS setup and master data management policy.
- Preparation of a standardized chart of accounts, posting setup, posting groups and dimensions for group reporting,
- Importing standardized dictionaries: country and currency codes, shipment methods, transport codes, transit codes, tariff numbers, post codes