Skip to main content

MDM and PIM demystified


OK there is a big difference between MDM and PIM.

Apparently not everyone agrees.  Regardless, things can become even more confusing when analysts, vendors, consultants, and academics all give you their perspective on what MDM and/or PIM really is. I know it’s hard to sort through it. But let’s try to keep it very simple.


Note 1: my apology to the experts to leave out important aspects
Note 2: I took inspiration for the example below by reading "Master Data Management", written by the well-respected David Loshin.

Now, take the following transaction from a generic order fulfillment system:


I am sure you have identified the three master data domains in this transaction:
  • Customer: Michele M. Arpaia
  • Product: Seat 15B (what about Flight 238?)
  • Location: Sydney, SYD, Melbourne, MEL

Can you see the beauty of MDM? Ideally, every transaction (occurring everywhere in your organization) relies on accurate, consistent, fresh, and complete master data. Look at the locations. Your transactional system(s) is able to refer to “Sydney” no matter how it is represented in other systems e.g. SYD. If you have this discipline in place, your business will reap huge benefits (there’s much more to it. To start, I’d suggest to read Loshin’s book).  

Let’s focus now on the product domain. Where does it come from? Typically, you get product information from various sources but the key point here to understand is that product information gets authored somewhere (ideally in PIM) and MDM consolidates it along with other master data elements like customer (and ideally linking the two domains together).

Let’s dig into it a bit further.

“Seat 15B” is a product on its own right. In fact, it has, among other things, a number of attributes associated with it, including the following: 
  • It is non-refundable
  • Standby permitted
  • The fare is subject to change
  • Limited seating

Flight 238” is also a product. It fact, it has attributes associate with it, such as departure gate, an arrival gate, an on-time departure, etc. Additionally, a flight is also associated with seats. More specifically, a flight can be seen as a container for seats. This association can be easily created and maintained in PIM. 
From my experience, I’d model “flight” as a non-sellable product associated with seats (which are sellable products). Attributes would be defined at “flight” level and at “seat” level; with an inheritance mechanism attributes defined at flight level would be inherited down to all the “seats” associated with it.

The morale of this story is simple: MDM and PIM may need each other. But don’t be scared…it is a journey that starts with what is really important (and top priority) for you: authoring product information or consolidate your master data scattered across your organisation. I acknowledge that this is a contested point of view, though.

But remember: the selection of a PIM or an MDM system should be the culmination of preparatory steps taken once your organization is prepared to make the hard decisions regarding business process modifications and data governance.

Recommended reading: “Product Information Management (PIM) Genus”. This is a superlative article written by Tom Marine. 

Image credit: MDM International

Comments

Michele Arpaia said…
Thank you for the nice words.
Glad you appreciate it.

Will have a look at sqiar soon and will come back to you.