Master Data Management System

Scenarios for practical use of Master Data Management System

Creating a new card

The Master Data Management System enables you to define any number of statuses, which can be useful at the moment of creating cards. In most organizations, creating cards requires the involvement of many persons at different approval levels. Managing this process by means of a workflow would be very difficult.

We present a different type of this process below. A local purchase manager has signed an agreement with a new vendor and would like to add this vendor to Microsoft Dynamics NAV. Because the company’s policy is based on central vendor data management, the vendor card has to be set up in a central database. Obviously, before the card is created, a master data manager at the headquarters’ has to check whether a card for this vendor has not been set up yet in the system in order to prevent duplicate entries. If the card has not existed before, it is created and sent to a subsidiary, The process takes longer compared to when the card is created only locally. Data consistency means also its reduced flexibility and longer master data change process. Therefore, it is important to consider which data categories should be synchronized.

Blocking changes in local cards

In the example above, the user in a subsidiary where Microsoft Dynamics NAV has been synchronized with a central database attempts to modify an item description. The item card is set up in a central database as a globally managed one. For this reason, users in the subsidiary are not able to modify fields blocked for editing at a global level. Following a modification of an item description, the system displays a message notifying the user that the change „is not permitted”. To enter any change, the user should notify a master data manager in the headquarters.

Managing chart of accounts used by subsidiaries

One of the most critical Master Data Management System usages is central management of chart of accounts used in subsidiaries. If accounts or group of accounts are defined as global ones in a central database, they cannot be modified at the subsidiary level (i.e. at the level of local companies or databases). This issue is usually solved by blocking modifications of account groups and enabling setup options for subsidiaries within a group. This ensures that the same chart of accounts structure is maintained within the group, ensuring flexibility at the local level at the same time. The global chart of accounts has been discussed broader in many locations of our website.

Adding a new company to a central data base

To add a new company to a central database which is to be synchronised, it is necessary to define several parameters and network folders for transfering data from a central database to a subsidiary. It should be emphasised that the creation of a company in a central database does not mean creating a company in Microsoft Dynamics NAV. The whole standardised process of company settup in Microsoft Dynamics NAV is managed in the same way.

Defining subsidiaries with databases where a card is to be created

In the previous example a new vendor card was created as there was not any card created in a central database. This is also happens when the headquarters’ call center receives a request to set up a new item card. If it turns out that such a card already exists, the company requesting for adding the item should be added to the database. In the example above, a global company manages item cards at a central level. For this reason, each new item (even if it is used by just one subsidiary) has to be entered first in a central database in order to replicate it to a local database. This ensures if any other company intends to use the item, it will be not able to create it independently in the system. This prevents inconsistencies across the organization. For this reason, at the level of a central database, we have implemented a tool which enables the user to easily assign each card to a group of the so called receivers.

If an item card is managed globally, data modification is possible only at the level of a central database. The screenshot above shows a sample item card in a company where only few fields are managed centrally. In such as situation, when data is dispalyed from a central database the data is visible in a simplified view. The card shows only the fileds which are managed centrally.

The benefits of using MDMS in Microsoft Dynamics NAV installations at customer companies –real-life examples

The primary benefits of implementing Master Data Management System for Microsoft Dynamics NAV include:

• Faster implementation of changes within the company – all modifications of global data (inventory, price lists, contractor data, etc.) are automatically transmitted to all subsidiaries.
• Simplified and more efficient data management from headquarters.
• Complete master data synchronization in all subsidiaries.
• Coherent technical and marketing data.
• Streamlined data exchange (including EDI).
• Production statistics – capability of comparing production data from multiple subsidiaries.
• Decreased inventory levels due to easier management of slow-moving stock in subsidiaries.
• Consolidation of costs and payables by means of central vendor card management.
• More effective control of receivables (both intercompany and external) using the cross-check of outstanding receivables and blocked customers.

In this article, we would like to describe three benefits our customers have gained which show how first example describes how one of our customers handled the problem of customer dishonesty, the second – deals with centralized method for creating cards, the third one – focuses on the production BOM standardization. An interesting issue i.e. Slow Moving Stock has been also discussed in another article.

Blocking customers and customer cards management in a global company

An interesting case we came across while working on the global Microsoft Dynamics NAV (Navision) roll-out in one of the companies was related to blocking customers. Individual subsidiaries had very similar business activity profiles. Thus, the same customers were able to place orders in different subsidiaries. It turned out that we could overcome this problem by implementing a centralized customer card management system.

Blocking customers by independent subsidiaries – Scenario 1

The entire group faced the problem of customer credit limit abuse. It was a standard procedure to block the customer once the credit limit was reached. It was supposed to make the customer settle their financial liabilities. However, some customers, blocked at one subsidiary, ordered services at another subsidiary. As subsidiaries did not share customer data, they had separate cards for each customer. Being unaware that the customer reached the credit limit at one location, subsidiaries granted new credit limits. As shown in the diagram below, the customer interacted with individual subsidiaries autonomously as all customer-related data was stored in multiple databases.

Central customer card management – Scenario 2

This problem was solved by implementing Master Data Management System for Dynamics NAV – used for administration of key data such as items, pricelists, customers and vendors. In this case, customer cards, specifying whether respective customers are blocked, are stored in one central database. Information about blocking the customer at one location is forwarded to other subsidiaries.  As illustrated in Scenario 2, once cooperation with a subsidiary is established, a customer card is created in the central database, not in the local database. Then, within one hour, the customer card is replicated into local databases. Establishing business relationship with one subsidiary entails automatic interaction with the whole group of companies. As a result, blocking customers is no longer the issue.

Centralized item creation process in a global company

The primary objective of global Dynamics NAV (Navision) standardization is to unify processes of various business locations and move a great deal of functionalities, previously supported by the subsidiaries, to the headquarters. The item creation process may be a good example to illustrate such an approach.

Multiple technical (design) departments at multiple locations – Scenario 1

In the case of one of our global customers, before Dynamics NAV implementation project (with standardized processes and settings) there were multiple design teams at various subsidiaries working simultaneously on the item design. It was the result of the group initial strategy, according to which all production facilities have their own technical (design) departments.

Moving the item creation process to the headquarters – Scenario 2

However, the group’s objective was to transfer all design-related activities to the headquarters. As a result of implementing Master Data Management System, all items are now created in one single location (central database). What is more, the item creation procedure was standardized as well. All item information (technical, marketing, general etc.) is now properly grouped and organized. Designing items, defining their parameters, assigning numbers etc. are the responsibilities of the technical department.

Group centralization with global Dynamics NAV platform

Group centralization would not be possible without the global platform based on Dynamics NAV that we provided to our client. The procedures of activity centralization had already started before the implementation of the standardized system. At some point, however, the support of IT tools was essential. The implemented Dynamics NAV platform operates under the assumption that all data will be centrally managed. As a result, one central project team was set up to design items and enter them into the central database. On the other hand, all subsidiaries work in a very similar manner: they all have standardized processes and data. As a consequence, the same instructions given by the central project team may be applied to all subsidiaries.

Standardization of BOMs in multiple production facilities

Lack of standardized card numbering used for inventory management in ERP systems (like Microsoft Dynamics NAV) is a common problem which many international companies face. It may often happen that the same item has different numbers in different local databases which results in diversified BOM* structures.

Multiple BOM components in various production facilities

Let me illustrate this with an example. One of our customers manufactured the same products (items) from various components in multiple production facilities. Some of them were able to manufacture all components on their own, but the smaller factories ordered the components from external vendors. Obviously, after putting all required components together the final product was the same. However, its structure was different, depending on which subsidiary produced it.

BOMs and items in the central database

The problem with BOM and inventory numbering can be solved by implementing Master Data Management System. With the support of the MDMS module, information about product (item) locations will be stored in one place regardless of whether they are manufactured internally or ordered from external sources. The idea behind this approach was that subsidiaries had no permissions to create new items or to modify them in their local databases. According to customers’ requirements all items, even those manufactured exclusively at one single subsidiary, are created in the central database. Obviously, other settings are also allowed. When it comes to data editing in item cards, local changes are possible only in the selected fields, depending on the settings.

Item cards in the local databases

If a subsidiary’s employee finds out that the required item does not exist in the local database, he logs into the MDMS central database and checks whether the item have already been created for the entire group. It may happen that the item exists physically but it cannot be found in the local database as it was not needed before. With the MDMS module, local databases do not  store all company data but only information (e.g. about inventory) which is needed at respective subsidiaries. The primary purpose of implementing MDMS is to streamline work in subsidiaries by storing in local databases only these cards that are needed at individual locations.

Selected items assigned to specific subsidiaries

If an item exists in the MDMS central database, the only thing to do is to add it to the list of subscribers – the subsidiaries, whose databases would store its card. In the next step, the item data will be sent to the local database. From that moment on, each time an item modification is made in the MDMS central database, relevant information is forwarded to the local database. If the item is not stored in the MDMS central database, an authorized employee in the headquarters with requested permissions  makes a decision whether to create the item and assign it to the subsidiary or not. Methods used for determining whether a given product (item) can be found in the MDMS central database have been discussed in more detail in the post on structured item numbering.

BOM template and local BOMs

As far as BOM and inventory standardization is concerned, the headquarters create a BOM template and then local BOMs for each subsidiary. The central BOM is a kind of a template. Starting from the  first use by the subsidiary, the local BOM can be modified at a request of employees responsible for production in given subsidiaries. However, changes are always made in the central database. Only then, are they forwarded to the local database. They are no longer editable, though.

If a BOM component is not produced on the company premises (as defined in the BOM template) but purchased from external sources, the local BOM requires relevant modifications. Special tools are used to compare BOMs used within the group, as each BOM template as well as all local BOMs are stored in the central MDMS database. On the other hand, changes of local BOM parameters are not allowed only in the local database. According to MDMS setup, all master data including local BOMs can be modified only in the MDMS central database. Once the changes are made, the relevant information is sent to the local database. As a result, any BOM used by the subsidiary is adjusted as well.

Pros and cons of using central BOM management

The entire process of modifying BOM-related data takes a bit longer than introducing changes only in the local database. From the group perspective, what we gain is central management and control of BOMs (including BOMs used only locally). On the minus side, the whole procedure of implementing changes is more time-consuming. Generally, production changes are introduced in the central MDMS database within one hour. On the other hand, when the headquarters decide to replace some components in all local BOMs, the entire process is performed very quickly.

* BOM (Bill of Materials) – a list of components and their quantities that are required to manufacture a final product.