The challenge I have traditionally encountered the analyst community (most but not all) is that analysis of Consulting organizations have always been evaluated as “Systems Integrators”. I am hoping that we now see a focus on organizations that focus on the business alignment, process expertise, and the alignment of information assets to improve business performance independent of firms that simply implement technologies. Two very different, distinct skill sets and should be looked at as such. I also believe that expertise will need to be evaluated by industry as understanding core processes and alignment to the processes to operationalize stewardship will be the greatest path to mitigate risk and drive adoption.

Just my 2 cents.

Chris

Thanks for the replay. I would agree that “PIM” vendors have struggled to meet the needs of “CDI” and equally “CDI” vendors have struggled to meet the needs of PIM. In fact we maintain two Magic Quadrants, one for the MDM of Product Data domain, and the other MDM of Customer Data domain. For some of the reasons you site, these two market segments out to be “MDM of ‘thing’” and “MDM of ‘party’” but that is not as impactful to the reader.

There are differences, and there are also similarities, in the needs of the two domain (or, at the thing and party level, provinces). Inheritance, common in data modeling for complex products, sometimes pops up in changes to sales territories, common in “analytical MDM”. While “PIM” is used to managing thousands of records, and thousands of attributes, “CDI” was used to handling large volumes of transactions for reasonably simple (by comparison) objects. Though CDI get’s pretty complicated in financial services sector… Then there are other “generalist” that call themselves “MDM” vendors (and they can model almost anything) but they rarely have any deep knowledge at the industry level; very important when you want ot know what one should do, and what to avoid. In days long gone I used to argue for “five levels of multi-level forecasting” because it worked, as a means to automatically improving the accuracy of a forecast, in thousands of implementations. That “best practice” would sometimes get lost to user who fell for the competing vendors who offered “unlimited levels of aggregation and disaggregation”. Just because something is possible does make it better.

I don’t see many “MDM tools” without a user interface these days. I can’t quite imaging “governing” anything without some screen presenting the status of the thing that is being governed. Look at all the CDI tools that now has a user interface. And look at the PIM vendors that moved (not all, yet) to secure access to party matching, merging and entity resolution capability. Sings of a market maturing, and elements converging.

So I agree with your opening point, CDI/MDM does not make a natural fit for PIM; just as PIM/MDM would not be a natural fit for CDI. However, it seems clear that CDI and PIM remain different sides to the came coin.

Your question above about MDM for Product vs. PIM is one that has always been a good topic for me to discuss. I’ve found that pure-play MDM products, or CDI products turned into PIM products aren’t quite the same as PIM, and are missing some things. Meanwhile, I would also contend you there are probably good PIM products available that don’t have full MDM functionality (and certainly not generic MDM functionality).

This is not the right place to go into things at length, but one example might help. Within PIM, there is a need to be able to easily manage product information for large numbers of products (10s of thousands, to millions at least). This requires tools for business users to do so efficiently. Tools to categorize products into a hierarchy and define attributes that are category specific. Then tools to easily manage the data via inheritance or mass editing. For those not familiar with PIM, think of this: hammers may need an attribute to describe their handle type (wood, fiberglass, steel, etc.). Power drills will not have that attribute, but may instead need voltage and horsepower attributes. And if you’re managing thousands of these things, you certainly don’t want to have to make changes by manually editing each one.

That’s just one example — but it also underscores an important point. You could build a fantastic generic MDM tool that has no user interface at all for editing data (only for inspecting, quality ranking, de-duplicating, selecting best sources, etc.). Not true in the PIM world.

Regards,

Robert

I can remember vivid discussions with professors in 1990 (during my study) about “how should we name direct marketing”. Database(d) (driven) marketing, one-on-one marketing, customer marketing, relationship marketing etc. A few years later we called it customer-based marketing management. We wanted to get rid of technical terms and included management to emphasize the role of the business. Vendors in that time used all different terms for their solutions. It took a few years before we ended up with CRM as a container definition.

CDI and PIM can indeed be solved with the same solution and many technologies, algorithms can be shared. But I still like to think SAP ERP is something different from SAP CRM. When our economies and industries make it possible to serve each customer uniquely than it will come together. Until than I think it is easier to make a distinction between PIM and CDI. One of the reasons is that the business users are completely different from each other.

Regards,

Ramon

Your post is very relevant. As system integrator we still fight every day against approaches envisaging MDM as a pure IT effort.

Even if I would not envisage MDM without data quality and data governance, I would not merge these concepts. I would go for a view where data quality and data governance are the backbone of the effort to put information at the heart of the business. This is where you will have to manage this huge challenge to change the habits, to build your stewardship network, to communicate the “What’s in it for me” to the organization, etc.

Once these foundations are in place, any information management initiative will share fundamentals – like enterprise business definitions, a data stewards network, etc. – and will quickly deliver added value. MDM for example is basically an answer to a need for transversal business processes across your organization and cannot be possible without a foundation of quality information.

We apply the same principle to the BI domain (having the same goal as MDM of a trusted single version of the truth but on decisional topics) with the introduction of the BICC having as key basis, data quality and data governance.

The MDM and PIM software industry needs to take a step back to understand actual day to day business requirements of data management to achieve Master Data Quality. Lesson one is that data is created and supplied by many sources in many different formats at various quality levels. Data is created by engineering, submitted by integrators, manufacturers and suppliers. To add to the complexity of the information flow, data is introduced into businesses systems in different departments (engineering or purchasing or maybe plant from maintenance) with different data requirements to meet the needs of that job function. Now the next dynamic is mashing new data to existing legacy data in a number of systems to ensure no duplicates are created, managing obsolete / recommended use and functional equivalents. The old philosophies of a PIM or MDM software to “hold, provide search functionality and maybe a shopping cart” isn’t going to meet the true requirements of the new definitions of Master Data Management.

To meet the new definitions the MDM or PIM software needs to provide horse power to electronically and intelligently processing data to identify exceptions for manual intervention by an analyst. Data should be processed one time to ensure that the data record will be enriched to meet the requirements of the enterprise and then the record is moved to a maintenance program (managed also by the MDM or PIM software). The processing of data needs to be efficient and cost effective, from my perspective the cost of data management should be covered by the cost saving achieved by MDM management.

I look forward to the discussions as the definition of MDM is expanded to include data quality, data governance, data provenience as the software industry provides the intelligence, functionality and business processes to cleanse, enrich and management data for my client to ensure their ability to make confident business decisions based on data integrity and accuracy.

Here is to the future of PIM and MDM!

When I hear a user admit, “I need governance” this is not meaningful since there is no context. What needs governing? “Data governance” implies governance of “data” but what on earth is “data”? Ask 3 analysts that question and you’ll go through 90 minutes and identify 26 different types of “data”.

So I agree with your point, but I would qualify it further. I think I have an understanding of what is implied with “Master Data Governance” or “Governance of Master Data”. And in our definition of MDM (as a discipline), such governance was always included. In fact, some would argue this is one of the main reasons (the lack of master data governance) that led to the formation of MDM.