What Should Your Master Data Management Handle?

Once you have made the decision to use master data management (MDM), the next step is to decide which data to manage. The decision should be fairly straightforward as there are only certain types of data that these systems can handle. The following categories will give you an idea of the criteria to be followed when selecting master data. All of these should be considered together when deciding if something qualifies as master data.

Read More: Grammar and Data Management

Behavior: To put it simply, here you will look at how the data interacts with other data. For example, in a transaction system, master data is usually involved with transactional data: a customer would purchase your product; your supplier would sell materials. To understand the difference between transactional data and master data, let’s compare them to nouns and verbs. Transactional data is like a verb; here we are referring to things like a sale, an email, a delivery, and so on. Master data can be considered a noun. Think of master data as falling into the following categories: person, place, thing, or process.

Life Cycle: Your master data may be described by the way it is read, created, updated, searched, or even deleted. You’ll find that the cycles will be different for each type of master data. Think about how a customer is created within a specific industry, and how that may vary from one industry to another.

Cardinality: As the number of elements in a set decrease, so do its chances of being considered a master data element. If an organization only has two customers, they would probably not consider those customers as master data. But of course, a company with thousands of customers would need to set those customers in their master data. To both companies, large and small, each customer has the same importance. The only difference is that the need for a master data solution increases as the cardinality increases.

Lifetime: There are certain things that can either be considered master data or transactional data depending on their volatility. A contract would be a good example of this. The determining factor would be its lifespan. A PR firm may have many different contracts with many different companies, each lasting a year or more. In this case, the contract would be considered master data. Contracts that are more short-term (lasting a day, week, or month) could be considered as transactional.

Complexity: If your asset is complex, you will want to consider it as master data. If it is a simple element, however, there is no need.

Value: If your data is very valuable, you may want to consider it as a master data element. Before you do so, you should also consider its complexity.

Volatility: Entities that have non-changing attributes typically do not require a master data entry. Even if something is complex and valuable, if it doesn’t change enough over time, it does not need to be considered as master data.

Reuse: If your data needs to be used by multiple systems, you must consider it as a master data entry. Otherwise, you’ll run the risk of duplicating information.