In Master Data Management (MDM) we strive to describe the core entities that are essential to running a business. Most of these entities are something that exists in the real-world. We can organize these entities in various groups as for example parties, things and locations or by their relation to the business buy-side, sell-side and make-side (production).

The challenge in MDM is, as in life in general, that we use the same term for different concepts and different terms for the same concept.

Here are some of the classic issues:

• An employee is someone who works within an organization. Sometimes this term must be equal to someone who is on the payroll. But sometimes it is also someone who works besides people on the payroll but is contracting and therefore is more like a vendor. Sometimes employees buy stuff from the organization and therefore acts as a customer.
• Is it called vendor or supplier? The common perception is that a vendor brings the invoice and the supplier brings the goods and/or services. This is often the same legal entity but not too seldom two different legal entities.
• What is a customer? There are numerous challenges in this question. It is about when a party starts being a customer and when the relationship ends. It is about whether it is a direct or an indirect customer. And also: Is it a business-to-consumer (B2C) customer, a business-to-business (B2B) or a B2B2C customer?
• Besides employees, vendors and customers (and similar terms) we also care about other parties being business partners. We care about those entities that we must engage with in order to influence our sales. In manufacturing or reselling building materials you for example build relationships with the architects and engineers who choose the materials to be used for a building.
• Traditionally product master data management has revolved around describing a product model which can be produced and sold in many instances over time. With the rise of intelligent things and individually configured complex products, we increasingly must describe each instance of a product as an asset. This adds to the traditional asset domain, where only a few valuable assets have been handled with focus on the financial value.
• Each party and each thing have one and most often several relationships with a geographic location (besides digital locations as for example websites).

The relationships within multi-domain MDM was examined further in the post 3 Old and 3 New Multi-Domain MDM Relationship Types.

Managing relationships between entities is a very important part of Master Data Management (MDM) as told in the post Another Facet of MDM: Master Relationship Management.

There are relationships between entities within the single MDM domains and there are relationships between entities across multiple MDM domains.

Related Parties

Within customer (or rather party) MDM establishing the relationships between entities heavily increases the value of the data assets. Examples are:

• In B2B (Business-to-Business) environments knowing about company family trees supports both analytic and operational challenges. That knowledge is often provided by enriching data from third party data providers, but as most things in life there is no silver bullet available, as the real world is quite complex and in no way fully covered by any provider I know about.
• In B2C (Business-to-Consumer) environments knowing about how individuals are related in households is key to many analytic and operational issues too. Here having high quality location data is a necessity.

Related Products

In today’s multi-channel world there is a rush for getting product entities enriched with a myriad of attributes to support customer self-service and thus as a minimum mimicking the knowledge of the traditional sales person in a brick and mortar store.

But we also need to mimic that sales persons knowledge about how products relates. That knowledge can be collected in different ways:

• From the manufacturer of the product. This source is often good when it comes to product relationship types as accessory and replacement (succession).
• From the customer. We know this approach from the online sales trick prompting us with the message “People who bought A also bought B”.
• From internal considerations. Facilitating up-sell can be done by enhancing product data with that kind of product relations.

Multi-Domain Relations

Here we may have:

• Relations between party master entities and product master entities as told in the post Customer Product Matrix Management.
• Relations between party master entities and location master data as examined in the post Location, Location, Location.
• Relations between product master data and location master data as reported in the post Product Placement.