No, this is not an(other) attempt to challenge Gartner, the analyst firm, in making quadrants about vendors in the Master Data Management (MDM) realm.
This an attempt to highlight some capabilities of Multi-Domain MDM solutions here focusing on party and product master data and the sell-side and the buy-side of MDM as discussed some years ago in the post Sell-side vs Buy-side Master Data Quality.
A simple quadrant will look like this:
- The upper right corner is where MDM started, being with solutions back then called Customer Data Integration (CDI).
- The Product Information Management (PIM) side is quite diverse and depending on the industry vertical where implemented:
- Retailers and distributors have their challenges with sometimes high numbers of products that goes in and comes out as the same but with data reflecting different viewing points.
- Manufacturers have other issues managing raw materials, semi-finished products, finish products and products and services used to facilitate the processes.
- Everyone have supplies.
- The supplier master data management has more or less also been part of the PIM space but looks more like customer master data and should be part of a party master data discipline also embracing other party roles as employee.
Also, this quadrant is by the way without other important domains as location (as discussed in the post Bringing the Location to Multi-Domain MDM) and asset (as discussed in the post Where is the Asset?)
These days I am attending the Gartner MDM summit in London.
MDM (Master Data Management) initiatives and MDM solutions are not created equal and different ways of slicing the MDM world were put forward on the first day.
Gartner is famous for the magic quadrants and during the customer master data quadrant presentation I heard Bill O’Kane explain why this is a separate quadrant from the product master data quadrant and why there are no challengers and no visionaries.
In another session about MDM milestones Bill O’Kane for this context sliced the MDM world a bit differently based on moving between MDM styles. Here we had:
- Business-to-consumer (B2C) Customer Data Integration (CDI)
- Business-to-business (B2B) customer MDM, Product Information Management (PIM) and other domains.
The vendors in general seems to want to do everything MDM.
Stibo Systems, a traditional PIM vendor, presented the case for multidomain MDM based on how things have developed within eCommerce. Stibo even smuggled the term omnidomain MDM into the slides. A marketing gig in the making perhaps.
The megavendors has bought who ever they need to be multidomain.
Some new solutions are born in the multidomain age. Semarchy is an interesting example as they are so the evolutionary way.
A recent infographic prepared by Trillium Software highlights a fact about data quality I personally have been preaching about a lot:
This number is (roughly) sourced from a study by Wayne W. Eckerson of The Data Warehouse Institute made in 2002:
So, in the fight against bad data quality, a good place to start will be helping data entry personnel doing it right the first time.
One way of achieving that is to cut down on the data being entered. This may be done by picking the data from sources already available out there instead of retyping things and making those annoying flaws.
If we look at the two most prominent master data domains, some ideas will be:
- In the product domain I have seen my share of product descriptions and specifications being reentered when flowing down in the supply chain of manufacturers, distributors, re-sellers, retailers and end users. Better batch interfaces with data quality controls is one way of coping with that. Social collaboration is another one as told in the post Social PIM.
- In the customer, or rather party, domain we have seen an uptake of using address validation. That is good. However, it is not good enough as discussed in the post Beyond Address Validation.
A recent blog post called Top 14 Master Data Management Misconceptions by William McKnight has as the last misconception this one:
“14. Third-party data is inappropriate for MDM
Third-party data is largely about extending the profile of important subject areas, which are mastered in MDM. Taking third-party data into organizations has actually kicked off many MDM programs.”
Indeed, using third-party data, which also could be called big external reference data, is in my eyes a very good solution for a lot of use cases. Some of the most popular exploitations today are:
- Using a business directory as big reference data for B2B party master data in customer data integration (CDI) and supplier master data management.
- Using address directories as big reference data for location master data management also related to party master data management for B2C customer data.
- Using product data directories such as the Global data Synchronization Network (GDSN®) services, the UNSPSC® directory and heaps of industry specific product directories.
The next wave of exploiting external data, which is just kicking off as Social MDM, is digging into social media for sharing data, including:
- Using professional social networks as LinkedIn in B2B environments where you often find the most timely reference data not at least about contact data related to your business partners’ accounts.
- Using consumer oriented social networks as Facebook for getting to know your B2C customers better.
- Using social collaboration as a way to achieve better product master data as told in the post Social PIM.
In MDM (Master Data Management) there is the term Multi-Domain MDM being how we manage respectively parties, products, locations and other entity types and handling master data within a Multi-Channel environment encompassing offline, online and social channels is a huge challenge within MDM today. Yet another multi view of MDM is handling different facets of master data being:
Handling entities is the core of master data management. Ensuring that master data are fit for multiple purposes most often by ensuring real world alignment is the basic goal of master data management. Entity resolution is at key discipline in doing that. In the party master data domain doing Customer Data Integration (CDI) is the good old activity aiming at compiling all the customer data silos in the enterprise into a golden copy with golden records. Product Information Management (PIM) is another ancestor in the MDM evolution history predominately focusing at the entities.
A possible distinction between Master Entity Management and Master Relation Management is discussed in the post Another Facet of MDM: Master Relationship Management.
As we get better and better solutions for handling entities the innovation shifts to handling the relationships between entities. These relations exists for example in Multi-Channel environments by linking entities in the old systems of record with the same real world entities in the new systems of engagement as told in the post Social MDM and Systems of Engagement.
Getting the master data right the first time is crucial.
In product master data management getting to that stage is often done by managing a flow of events where the product data are completed and approved by a team of knowledge workers.
In party master data management a way of ensuring first time right is examined in the post instant Single Customer View. But that is only the start. Party master data has a life cycle with important events as:
This year’s version of the MDM (Master Data Management) Landscape report from Information Difference is out.
The report confirms some trends in MDM offerings also mentioned here on the blog. Some sayings from the Information Difference report are:
- “The market is starting to dabble in cloud-based implementations…”
- “There continues to be a demand for MDM offerings to handle reference data….”
- “ …still very much in their early stages, are support for Big Data…”
Categorizing the vendors into the traditional division of Customer Data Integration (CDI) versus Product Information Management (PIM) support is becoming less relevant as new Multi-Domain offerings are coming out and larger Product Master Data specialists as Hybris and Heiler has been snapped by megavendors. This leaves Stibo as the only remaining large PIM vendor, but Stibo has actually already rebranded themselves as a Multi-Domain player and have been working seriously on that for a couple of years.
You may view the full Information Difference MDM Landscape report here.
On the upcoming MDM Summit Europe 2013 in London this April you will be able to learn about Multi-Entity MDM as well as Multi-Domain MDM.
So, what is the difference between Multi-Entity MDM and Multi-Domain MDM?
To my knowledge it is two terms having the same meaning. It is doing the two main preceding disciplines for MDM being Customer Data Integration (CDI) and Product Information Management (PIM) at the same time presumably using the same software brand.
Multi-Entity MDM was probably the first term used and still used by The MDM Institute while Multidomain MDM is used by Gartner (the analyst firm) and most tool vendors today. For example Stibo Systems is focusing on mutidomain recently in this press release about latest achievements.
Talking about Gartner and the vendor crowd Gartner analyst Andrew White wrote a blog post the other day: Round-Up of Master Data Management (MDM) 2012, and looking forward to 2013.
Herein White bashes the vendors by saying:
“Vendor hype related to multidomain …. continued to be far in excess of reality”.
What do you think? Is Andrew White right about that? And what about Multi-Entity MDM, is that any better?
As reported in the post What to do in 2012 doing Master Data Management (MDM) in the cloud is one of three trends within MDM that according to Gartner (the analyst firm) will shape the MDM market in the coming years.
Doing MDM in the cloud is an obvious choice if all your operational applications are in the cloud already. Such a solution was presented on Informatica Perspectives in the blog post Power the Social Enterprise with a Complete Customer View. The post includes a Video where the situation with multiple instances of SalesForce.com solutions within the same enterprise is supported by a master data backbone in the cloud.
But even if all your operational applications are on premise you may start with lifting some master data management functionality up in the cloud. I am currently working with such a solution.
When onboarding customer (and other party) master data much of the basic information needed is already known in the cloud. Therefore lifting the onboarding functionality up into the cloud makes a lot of sense. This is the premise, so to speak, for the MDM edition of the instant Data Quality (iDQ) solution that we are working on these days.
Cloud services for the other prominent MDM domain being product master data also makes a lot of sense. As told in the post Social PIM a lot of basic product master data may be shared in the cloud embracing the supply chain of manufacturers, distributors, retailers and end users.
In both these cases some of the master data management functionality is handled in the cloud while the data integration stuff takes place where the operational applications resides be that in the cloud and/or on premise.
Keystrokes are evil. Every keystroke represents a potential root cause of poor data quality by spelling things wrongly, putting the right thing in the wrong place, putting the wrong thing in the right place and so on. Besides that every keystroke is a cost of work summing up with all the other keystrokes to gigantic amounts of work costs.
In master data management (MDM) you will be able to getting things right, and reduce working costs, by killing keystrokes wherever possible.
Killing keystrokes in Product Information Management (PIM)
I have seen my share of current business processes where product master data are reentered or copied and pasted from different sources extracted from one product master data container and, often via spreadsheets, captured into another product master data container.
This happens inside organizations and it happens in the ecosystem of business partners in supply chains encompassing manufactures, distributors and retailers.
As touched in the post Social PIM there might be light at the end of the tunnel by the rise of tools, services and platforms setting up collaboration possibilities for sharing product master data and thus avoiding those evil keystrokes.
Killing keystrokes in Party Master Data Management
With party master data there are good possibilities of exploiting external data from big reference data sources and thus avoiding the evil keystrokes. The post instant Data Quality at Work tells about how a large utility company have gained better data quality, and reduced working costs, by using the iDQ™ service in that way within customer on-boarding and other business processes related to customer master data maintenance.
The next big thing in this area will be the customer data integration (CDI) part of what I call Social MDM, where you may avoid the evil keystrokes by utilizing the keystrokes already made in social networks by who the master data is about.
The term social commerce is said to be a subset of eCommerce where social media is used to ultimately drag prospects and returning customers to your website, where a purchase of products and services can be made.
In complex sales processes, typically for Business-to-Business (B2B) sales, the website may offer product information sheets, demo requests, contact forms and other pipeline steps.
This is the moment where your social media engaged (prospective) customer meets your master data as:
- The (prospective) customer creates and maintains name, address and communication information by using registration functions
- The (prospective) customer searches for and reads product information on web shops and information sites
One aspect of this transition is how master data is carried over, namely:
- How the social network profile used in engagement is captured as part of (prospective) customer master data or if it should be part of master data at all?
- How product information from the governed master data hub has been used as part of the social media engagement or if the data governance of product data should be extended to use in social media at all?