Multi-Domain MDM and PIM, Party and Product

Multi-Domain Master Data Management (MDM) and Product Information Management (PIM) are two interrelated disciplines within information management.

While we may see Product Information Management as the ancestor or sister to Product Master Data Management, we will in my eyes gain much more from Product Information Management if we treat this discipline in conjunction with Multi-Domain Master Data Management.

Party and product are the most common handled domains in MDM. I see their intersections as shown in the figure below:

Multi-Side MDM

Your company is not an island. You are part of a business ecosystem, where you may be:

  • Upstream as the maker of goods and services. For that you need to buy raw materials and indirect goods from the parties being your vendors. In a data driven world you also to need to receive product information for these items. You need to sell your finished products to the midstream and downstream parties being your B2B customers. For that you need to provide product information to those parties.
  • Midstream as a distributor (wholesaler) of products. You need to receive product information from upstream parties being your vendors, perhaps enrich and adapt the product information and provide this information to the parties being your downstream B2B customers.
  • Downstream as a retailer or large end user of product information. You need to receive product information from upstream parties being your vendors and enrich and adapt the product information so you will be the preferred seller to the parties being your B2B customers and/or B2C customers.

Knowledge about who the parties being your vendors and/or customers are and how they see product information, is essential to how you must handle product information.  How you handle product information is essential to your trading partners.

You can apply party and product interaction for business ecosystems as explained in the post Party and Product: The Core Entities in Most Data Models.

3 Old and 3 New Multi-Domain MDM Relationship Types

Master Data Management (MDM) has traditionally been mostly about party master data management (including not at least customer master data management) and product master data management. Location master data management has been the third domain and then asset master data management is seen as the fourth – or forgotten – domain.

With the rise of Internet of Things (IoT) asset – seen as a thing – is seriously entering the MDM world. In buzzword language, these things are smart devices that produces big data we can use to gain much more insight about parties (in customer roles), products, locations and the things themselves.

In the old MDM world with party, product and location we had 3 types of relationships between entities in these domains. With the inclusion of asset/thing we have 3 more exiting relationship types.

Multi-Domain MDM Relations

The Old MDM World

1: Handling the relationship between a party at its location(s) is one of the core capabilities of a proper party MDM solution. The good old customer table is just not good enough as explained in the post A Place in Time.

2: Managing the relationship between parties and products is essential in supplier master data management and tracking the relationship between customers and products is a common use case as exemplified in the post Customer Product Matrix Management.

3:  Some products are related to a location as told in the post Product Placement.

The New MDM World

4: We need to be aware of who owns, operates, maintains and have other party roles with any smart device being a part of the Internet of Things.

5: In order to make sense of the big data coming from fixed or moving smart devices we need to know the location context.

6: Further, we must include the product information of the product model for the smart devices.

Expanding to Business Ecosystems

In my eyes, it is hard to handle the 3 old relationship types separately within a given enterprise. When including things and the 3 new relationship types, expanding master data management to the business ecosystems you have with trading partners will be imperative as elaborated in the post Data Management Platforms for Business Ecosystems.

IoT and Multi-Domain MDM

The Internet-of-Things (IoT) is a hot topic and many Master Data Management (MDM) practitioners as well as tool and service vendors are exploring what the rise of the Internet-of-Things and the related Industry 4.0 themes will mean for Master Data Management in the years to come.

globalIn my eyes, connecting these smart devices and exploiting the big data you can pull (or being pushed) from them will require a lot for all Master Data Management domains. Some main considerations will be:

  • Party Master Data Management is needed to know about the many roles you can apply to a given device. Who is the manufacturer, vendor, supplier, owner, maintainer and collector of data? Privacy and security matters on that basis will have to be taken very seriously.
  • Location Master Data Management is necessary at a much deeper and precise level than what we are used to when dealing with postal addresses. You will need to know a home location with a timespan and you will need to confirm and, for moving devices, supplement with observed locations with a timestamp.
  • Product and Asset Master Data Management is imperative in order to know about the product model of the smart device and individual characteristics of the given device.

It is also interesting to consider, if you will be able to manage this connectivity within a MDM platform (even multidomain and end-to-end) behind your corporate walls. I do not think so as told in the post The Intersections of 360 Degree MDM.

Golden Records in Multi-Domain MDM

The term golden record is a core concept within Master Data Management (MDM). A golden record is a representation of a real world entity that may be compiled from multiple different representations of that entity in a single or in multiple different databases within the enterprise system landscape.

GoldIn Multi-domain MDM we work with a range of different entity types as party (with customer, supplier, employee and other roles), location, product and asset. The golden record concept applies to all of these entity types, but in slightly different ways.

Party Golden Records

Having a golden record that facilitates a single view of customer is probably the most known example of using the golden record concept. Managing customer records and dealing with duplicates of those is the most frequent data quality issue around.

If you are not able to prevent duplicate records from entering your MDM world, which is the best approach, then you have to apply data matching capabilities. When identifying a duplicate you must be able to intelligently merge any conflicting views into a golden record.

In lesser degree we see the same challenges in getting a single view of suppliers and, which is one of my favourite subjects, you ultimately will want to have a single view on any business partner, also where the same real world entity have both customer, supplier and other roles to your organization.

Location Golden Records

Having the same location only represented once in a golden record and applying any party, product and asset record, and ultimately golden record, to that record may be seen as quite academic. Nevertheless, striving for that concept will solve many data quality conundrums.

GoldLocation management have different meanings and importance for different industries. One example is that a brewery makes business with the legal entity (party) that owns a bar, café, restaurant. However, even though the owner of that place changes, which happens a lot, the brewery is still interested in being the brand served at that place. Also, the brewery wants to keep records of logistics around that place and the historic volumes delivered to that place. Utility and insurance is other examples of industries where the location golden record (should) matter a lot.

Knowing the properties of a location also supports the party deduplication process. For example, if you have two records with the name “John Smith” on the same address, the probability of that being the same real world entity is dependent on whether that location is a single-family house or a nursing home.

Product Golden Record

Product Information Management (PIM) solutions became popular with the raise of multi-channel where having the same representation of a product in offline and online channels is essential. The self-service approach in online sales also drew the requirements of managing a lot more product attributes than seen before, which again points to a solution of handling the product entity centralized.

In large organizations that have many business units around the world you struggle with having a local view and a global view of products. A given product may be a finished product to one unit but a raw material to another unit. Even a global SAP rollout will usually not clarify this – rather the contrary.

GoldWhile third party reference data helps a lot with handling golden records for party and location, this is lesser the case for product master data. Classification systems and data pools do exist, but will certainly not take you all the way. With product master data we must, in my eyes, rely more on second party master data meaning sharing product master data within the business ecosystems where you are present.

Asset (or Thing) Golden Records

In asset master data management you also have different purposes where having a single view of a real world asset helps a lot. There are namely financial purposes and logistic purposes that have to aligned, but also a lot of others purposes depending on the industry and the type of asset.

With the raise of the Internet of Things (IoT) we will have to manage a lot more assets (or things) than we usually have considered. When a thing (a machine, a vehicle, an appliance) becomes intelligent and now produces big data, master data management and indeed multi-domain master data management becomes imperative.

You will want to know a lot about the product model of the thing in order to make sense of the produced big data. For that, you need the product (model) golden record. You will want to have deep knowledge of the location in time of the thing. You cannot do that without the location golden records. You will want to know the different party roles in time related to the thing. The owner, the operator, the maintainer. If you want to avoid chaos, you need party golden records.

PIM Supplier Portals: Are They Good or Bad?

A recent discussion on the LinkedIn Multi-Domain MDM group is about vendor / supplier portals as a part of Product Information Management implementations.

A supplier portal (or vendor portal if you like) is usually an extension to a Product Information Management (PIM) solution. The idea is that the suppliers of products, and thus providers of product information, to you as a downstream participant (distributor or retailer) in a supply chain, can upload their product information into your PIM solution and thus relieving you of doing that. This process usually replace the work of receiving spreadsheets from suppliers in the many situations where data pools are not relevant.

In my opinion and experience, this is a flawed concept, because it is hostile to the supplier. The supplier will have hundreds of downstream receivers of products and thus product information. If all of them introduced their own supplier portal, they will have to learn and maintain hundreds of them. Only if you are bigger than your supplier is and is a substantial part of their business, they will go with you.

Broken data supply chainAnother concept, which is the opposite, is also emerging. This is manufacturers and upstream distributors establishing PIM customer portals, where suppliers can fetch product information. This concept is in my eyes flawed exactly the opposite way.

And then let us imagine that every provider of product information had their PIM customer portal and every receiver had their PIM supplier portal. Then no data would flow at all.

What is your opinion and experience?

The Intersections of 360 Degree MDM

In the Master Data Management (MDM) realm we have some common notions, being

  • 360 degree Customer Master Data Management, meaning how different views on customers in a company’s various business units and sales channels can be handled as a shared single view.
  • 360 degree Vendor (or Supplier) Master Data Management, meaning how different views on vendors/suppliers in a company’s various business units and supply chains can be handled as a shared single view.
  • 360 degree Product Master Data Management, meaning how different views on products in a company’s various business units, sales channels and supply chains can be handled as a shared single view.

Multi-Side MDM

Multi-Domain Master Data Management (MDM) is the discipline that brings all these views together. Here it is not enough that the same brand of technology is used for all three domains. Handling the intersections is the important part.

The intersection of Vendor/supplier and Customer is known as the Party Master Data domain. My recommendation is to have a common party (or business partner) structure for identification, names, addresses and contact data. This should be supported by data quality capabilities strongly build on external reference data (third party data). Besides this common structure, there should be specific structures for customer, vendor/supplier and other party roles.

The Vendor/supplier and Product Master Data intersection is related to buying products, namely how to on-board data about the vendor/supplier as a party, in the vendor role (financial stuff), the supplier role (logistic stuff) and then on-boarding his product information. My recommendation for on-boarding product information from suppliers being manufacturers is to make this a Win-Win solution for both parties as described in the post How a PLM-2-PIM Solution Becomes a WIN-WIN Solution.

The Customer and Product Master Data intersection is about supporting how you sell products. The term omnichannel is popular for that these days. Again, Product Information Management (PIM) plays a crucial role here and my recommendations for that is expressed in the post Adding Business Ecosystems to Omnichannel.

Multi-Domain MDM 360 and an Intelligent Data Lake

This week I had the pleasure of being at the Informatica MDM 360 event in Paris. The “360” predicate is all over in the Informatica communication. There are the MDM 360 events around the world.  The Product 360 solution – the new wrap of the old Heiler PIM solution, as I understand it. The Supplier 360 solution. Some Customer 360 stuff including the Cloud Customer 360 for Salesforce edition.

GW MDMAll these solutions constitutes one of the leading Multi-Domain MDM offerings on the market – if not the leading. We will be wiser on that question when Gartner (the analyst firm) makes their first Multi-Domain MDM Magic Quadrant later this year as reported in the post Gravitational Waves in the MDM World.

Until now, Informatica has been very well positioned for Customer MDM, but not among the leaders for Product MDM in the ranking according to Gartner. Other analysts, as Information Difference, have Informatica in the top right corner of the (Multi-Domain) MDM landscape as seen here.

MDM and big data is another focus area for Informatica and Informatica has certainly been one of the first MDM vendors who have embraced big data – and that not just with wording in marketing. Today we cannot say big data without saying data lake. Informatica names their offering the Intelligent Data Lake.

For me, it will be interesting to see how Informatica can take full Multi-Domain MDM leadership with combining a good Product MDM solution with an Intelligent Data Lake.

Bookmark and Share