What is the difference between Product Information Management and Master Data Management anyway?

Share it

Ducks-in-a-row

When people at a private dinner party ask me what kind of business I am in, I sometimes make the mistake of injecting words like Product Information Management and Master Data Management into my reply.

This is unfortunately often a bit of a conversation killer, and more often than not I am met with glazing eyes and either the conversation dies right then, or there is made an attempt to steer the conversation towards safer subjects such as the latest vacation destination or about how fast children grow up.

Occasionally, some people do manage to keep a straight face and ask polite questions about what it is, and what it is used for, and so on.

In the rare event that the conversation actually goes down that path, a typical follow-up question is something like:

“So what is the difference between Product Information Management and Master Data Management?”

Suddenly, I am the one who feels like changing the subject. Not because I don’t have an idea of how to answer, but because I’m afraid that by dragging my conversation partner through this answer, I will jeopardize my status in the community and possibly get banned from all future social events.

In the following I will, however, take the opportunity to provide the answer here – well, at least my take on it.

I recently read an article in which the author stated that the term Product Information Management was, by now, absorbed by Master Data Management and that it no longer made sense to talk about Product Information Management.

I do agree that the terms are blurry and with a fair bit of overlap, but I do still think there is a place for both terms and to understand this, you need to look at the history behind each of them.

The concept of Product Information Management roots back to the late 1990s as the Internet and other electronic media became popular and companies accustomed to marketing their products via printed catalogs, for example, were challenged with providing product information across all these new channels with a consistent message and doing so without exploding headcounts.

Many companies started out by having separate systems for each output channel, and for companies with any significant data volume that quickly turned out poorly due to issues of keeping data in sync between systems and the double effort that was involved in maintaining it. Exchanging the data between systems was often not feasible due to all kinds of media-specific structures and formatting issues.

Product Information Management was the solution that made it possible to create and maintain one record of a product in a database, and then share and publish all the product information to all media channels, such as printed and web catalogs, based on this one record.

This solved a big problem for the people in the company that were responsible for bringing the product information to the marketplace and in front of the customers: the marketing department.

Product Information Management was therefore born primarily as a marketing application.

In many companies, it turned out to stay that way for a long time (and in some cases even still) despite the obvious advantages to be had by connecting the product information to the rest of the company’s operational data. But Marketing’s appetite for involving other parts of the business was often minimal.

Marketing managers were faced with real problems that were impacting their ability to deliver results. If they were to implement a system that should be fully integrated into the company’s existing IT infrastructure, they would risk losing control of the project and become dependent on getting sufficient internal IT resources, not to mention the buy-in needed from the rest of the organization.

The marketing department’s issues were not necessarily first in line at IT management. They were often busy implementing or upgrading ERP systems or Data Warehouse technology, and thus IT resources were hard to come by.

This paved the way for externally hosted solutions that went under the IT management radar or at least required minimal internal IT resources. This way a marketing manager could get a solution to his problems without worrying about whether the server hardware, operating system, database technology etc. was supported by his own IT department.

It enabled Marketing to deploy a system fairly quickly and start reaping the benefits of Product Information Management. Hurrah!

However, in many cases this had the side effect that the system only got loosely integrated with the rest of the organization’s IT infrastructure, and the Product Information Management system often became a silo of information.

It was not a problem initially, but the fact that the company’s products also existed as individual records in various other business applications – often with several overlapping attributes – there were different “truths” of a product floating around in the company.

So people in Marketing and people in Finance could have conflicting information about the same product, and customers would see one set of information on the website, but a different set of information about the same product in the proposal or on the invoice. Hmm…

Meanwhile at the IT department…

As the IT department got underway with the implementation of the ERP system, they realized that the existing IT infrastructure was one big incoherent mess of Frankensteined point-to-point integrations held together by duct tape.

Countless stand-alone applications were running in all corners of the business, and although there was a huge overlap of the data being processed in each application, the integrations between applications were flaky, costly and incomplete.

This meant that, for example, product data would exist in several variations around the organization with a huge overlap of attributes being maintained in several different places independently of each other.

To solve this problem came Master Data Management. It’s basically the concept of establishing one source of data that is referenced wherever it is used around the organization. A strict set of rules is defined for where the information about each data record should be maintained, and where you should go look for available information about this record.

But Master Data Management is not just about the product information. It is about all the different types of data (aka domains) that run through an organization, such as data about customers, suppliers, employees, locations and so on.

This is a discipline that goes far beyond the realms of Marketing or any other single department. It is a cross-organizational effort to gather, manage and distribute data in the most efficient way possible.

And this is really where I see the big difference between Product Information Management and Master Data Management.

In Product Information Management, the driving force behind the initiative is to achieve a specific business capability: To enable a multi-channel marketing strategy with printed and web catalogs fed from one source, or maybe solely to feed an eCommerce website with rich product information in order to enable online customers to find the products they are looking for through advanced filtering and search functionality and offering up-sell/cross-sell options, product documentation, training videos etc.

In Master Data Management, your focus is to get all your ducks in row in your back-end in pursuit of operational excellence and once you are in complete control of your data, it is much easier to build new business capabilities on top of your solution. So the overarching goal is not to solve the Marketing manager’s immediate problems, but rather to create a foundation and set of processes that enable you to solve his problems in the long term. Some people may object here, but I am painting with a broad brush, OK?

So this is where I see the theoretical differences.
In the real world, the difference can be much harder to spot.

Product Information Management systems are still being implemented solely to solve specific business problems for Marketing without worrying too much about the back-end. This can make perfect sense if you are looking for fast results and cannot wait for your entire organization to follow along.

That’s a choice you can still make, but Product Information Management is not just about that anymore. As the thinking around Product Information Management and the vendor’s offerings have matured over the last decade, a best-practice implementation of Product Information Management today does indeed take the back-end of the business into consideration and adopts the virtues of Master Data Management by ensuring that only a single view of a product exists within the business, and it will try to tie all the loose ends together.

At the same time, you have varying degrees of Master Data Management being implemented. In fact, many current implementations of Master Data Management only cover a single domain such as customer or product data.

Only within the last few years we have seen vendors announce multi-domain Master Data Management capabilities, meaning one software solution that can manage all data domains and as far as I can tell, it is not yet the norm in real life implementations. At least not implemented within a single project, but rather with a stepping-stone approach, taking one piece of the puzzle at a time.

And that is where you find the overlap between Product Information Management and Master Data Management. If done right, you could consider your Product Information Management project to be the first phase of a long-term Master Data Management strategy, but with a clear focus on short-term business capabilities. It may take more effort up front, but it could well be a wise investment in the longevity and sustainability of your Product Information Management solution.

At the end of the day, it is all about which words we use to describe what we do. And with the definitions constantly evolving, it can be hard to put a label on a specific implementation or technology. It is, first and foremost, designed and shaped to solve actual business problems and provide competitive advantages for the organization. And what difference does the word we use make anyway, as long as the solution works and has a firm ground to stand on?

So the next time I have a dinner conversation that goes down the wrong path, maybe I will just show them this article – but then again, I could just ask about the latest vacation instead…

Share it

Comments

  1. Alberto Tapia says:

    Funny, with and historical touch (always important in our industry and often misvalued) and perfectly written. Thanks for this article! spot on!

  2. Hi Martin a very good article.
    I have also heard the term “Golden record” when referring to MDM. A golden record at the MDM solution will be the best known source of truth based on data input from different sourcing systems. (Often legacy systems). Thus the quality of the Golden Record is highly dependent of the data quality from those systems.

  3. Yes. Nice article
    Actually, there can be many misundestandings on words as you mention (PIM/MDM) because concepts evolve with new customers need or marketing, etc.
    Never hesitate to be redundant and to give concrete examples in real life to make it clear to the reader.

  4. A. Zug says:

    big like! Do you treat this is a global picture onto the topic or do you have experiences in different developments in e.g. the US or Asian market?

  5. Awesomely narrated post, totally enjoyed reading it. Thanks for the share!

Speak Your Mind