kurthatlevik: Master data concepts

[Blog bot]

Источник: https://kurthatlevik.wordpress.com/2...data-concepts/
==============

In Dynamics AX, we have been blessed that we can have most of the data in one system, and in one single database. But I sense a shift, where systems are breaking up into more loosely best-of-breed components. We see the introduction of Omi-channels, SaaS, RESTful Web services and ODATA as accelerators into this area.

The generic topic of Master data management(MDM) is much less about technology and much more about understanding how business processes are supposed to work. The principle of MDM is applied whenever two or more business processes must view or share (master) data. This means that all companies have a need for the discipline of MDM, meaning that it must be driven by the business, a business case, and supported/enabled by IT. This includes governance and data quality, and MDM cannot be established without them.

In my profession, when working with our internal EG-Retail model we are covering the Master Data Management processes from life-cycle data management to data distribution to POS-systems. As you see, there are not much directly related to the functionality of Dynamics AX, but more against how to create work processes that maintains and secures a company’s master data.



Master data lifecycle


The most common area where life-cycle processes are used are on products. Products are introduced, created, maintained, discontinued and finally archived or deleted. A lifecycle also involved different roles and departments, and the responsibility and master data ownership is changed through the lifecycle. It could be visualized like this, where effort in the processes is shown.



In terms of responsibility I also see the benefit of separating the roles of Master Data owner and requester, and introducing clear formal processes.

 

Create master data


Master data are the critical nouns of a business and falls into four groupings: people, things, places, and concepts. Further categorizations within those groupings are called subject areas, domain areas, or entity types. For example, within people, there are customer, employee, and salesperson. Within things, there are product, part, store, and asset. Within concepts, there are things like contract, warrantee, and licenses. Finally, within places, there are office
locations and geographic divisions.



The process of identifying additional Master Data elements should be a formalized process and an ownership process must be in place.



Creating master data is the process of collecting the accurate and persistent data related to each master data element. It is not only important to just enter the data, but also to identify
the source of the master data. In a data maintenance scenario, the process and master data owner may return to the source to collect more details. When creating master data, the completeness must be defined. Define what Master Data elements are mandatory and optional. What related master data must be in place to correctly create the master data.

As described above, all Master Data will have a life cycle. When creating, often only a minimum set of mandatory data elements are required. The life cycle and status should reflect the completeness of the master data.

Master data may originate from many different resources, roles and process participants. Timing is also relevant, because different data elements may only be needed on a later stage. An example is that certain set of data elements is needed when purchasing a product. When selling the product another set of data needs to be in place before this process can start.

A more formal process of handling Master Data will ensure that the quality and relations are taken into consideration. The following process should include both a requester and the master data owner, so ensure the formality.



When the master data is complete enough to be used for selected processes, the master data must be released and available in the systems where it is used. Examples are the procurement process where only a small subset of information is needed to initiate the purchasing process. But in order to receive the product at the warehouse, the product must be released to the warehouse management system. This require additional information and timing. In integrations, the release process of master data must be controlled and tracked. Before release of master data, the required completeness and data quality must be decided and confirmed.

Maintain master data


As requirements is expanding and changing, the master data will also have the need to change. Maintaining completeness and quality of master data becomes a central part in the life cycle Master Data management. Typically new markets and countries will request the need for new prices, VAT/Tax compliance and translations. Establishing maintenance processes will not only be essential for growth and expansions, but also to support day-to-day processes. The key principle is to centralize master data update around specific roles and processes. The generic maintenance process is reflecting this.



Discontinuation of master data


Deleting Master Data is generally not recommended. The reason is that the master data often have been used and related to transactions, and often in other systems like WMS, eCommerce etc. A better approach is the discontinuation process. If master data still should be deleted, it is important to analyze the consequences, and to initiate clean-up processes.

The discontinuation phase begins when the maintenance phase ends. Master data discontinuation is often a planned process, where the date of the discontinuation is set in advance. The discontinuation can also be related to specific processes, like a product is discontinued for procurement, but not for sale.

It is recommended must implement a structured life cycle process on master data, to control the situations where a master data record is discontinued or replaced with a new master data record. In this future process, we expect that the participants are the Master Data Owners and the MDM Administrator. The main purpose of the process is to support the actual discontinuation or depletion of Master Data Records in the AX system.

The input to the process is an online request or need for discontinuation or depletion of a Master Data Record. The output of the process is an updated Master Data Record in AX with the specified data from the request.

The process diagram below outlines an example of the future process for the discontinuation or depletion of existing Master Data Records in AX. In this process, we distinguish between discontinuation and depletion. In relation to products, the discontinuation only applies for specific SKU’s whereas depletion applies for all. (Like flushing out master data from an integrated system)



If it is expected that the growth of the data will accelerate as more partners and stores is connected to the installation, then archiving and purging will be important to keep an optimized performance of the Microsoft Dynamics AX installation. Before a master data record can be archived and deleted, other data (such as purchasing documents) that refer to the master data must themselves be archived. Both the purge and archive operations depend on a carefully determined hierarchical relationship of related tables based on both master data, settings and transactions. The archiving and purging process is too complex to be manually handled, because of the many relationships that exists to master data. It is therefore recommended to look into tools like the Microsoft Dynamics AX Intelligent Data Management Framework (IDMF) that can be used for this purpose.

IDMF have the following process.



Taking easy on master data processes can result and complete failure of your system and processes. When implementing Dynamics AX, make sure that enough time is invested to create a clear strategy, and good processes.

Happy DAX’ing J




Источник: https://kurthatlevik.wordpress.com/2...data-concepts/