We all know the problem: We use the same term, but means two different things. Or: We use two different terms, but actually mean the same thing.
Within data management this is a huge challenge. The solution is ….. Well, there are different terms:
Business Glossary is one term. The term is explained in an artcle on B-eye-Network by Lowell Fryman here. Using the term business glossary implies that you have a business approach to the issue. Implementing a business glossary is often mentioned as a part of a data governance framework.
Data Dictionary is explained on Wikipedia here. Using the term data dictionary implies that you have a technical approach to the issue. Having a data dictionary is sometimes mentioned as a part of a Master Data Management (MDM) solution.
Metadata Repository is also explained on Wikipedia here. Using the term metadata repository implies that you have a somewhat nerdish approach to the subject as seen in the post Metadata Meatballs. Addressing metadata is often stated as an important subject within the data quality discipline as shown in the post Perfect Wrong Answer.
Gartner, the analyst firm, recently released their magic quadrant for Master Data Management (MDM) of customer data solutions 2014 as reported in the post Customer MDM Magic Wordles.
Now the quadrant for Master Data Management of product data solutions 2014 is out too, so we can overlay the two quadrants and see how multi-domain Master Data Management (MDM) solutions are doing in terms of who are performing well with product master data and who are performing well with customer master data.
If we focus on leading vendors with differences in quadrant positioning, Informatica is better positioned with customer master data (leader) than with product master data (visionary and niche with two different products). Stibo Systems and Riversand are positioned very well within product master data (leaders) but not positioned at all with customer master data, though both vendors are naming themselves as multi-domain MDM solution providers and surely have such capabilities. I personally worked on the multi-domain roadmap with one of them some years ago.
This is not the quadrant. Just some vendor names.
As every year the vendors makes press releases about the quadrant.
Upen Varanasi, CEO of Riversand, has commented in this way: “In this new Digital world, accurate product and other master information is a foundation for our customers’ major business initiatives, which requires a comprehensive, highly scalable and flexible MDM solution with full multi-domain capabilities.” See the full press release from Riversand here.
Mikael Lyngsø, CEO of Stibo Systems says: “Every member of the Stibo Systems’ team remains committed to providing our customers and partners with cutting edge solutions that not only meet their most pressing business issues but also create the most lasting and demonstrable value.” The about the company section has this bold statement: “Stibo Systems is the global leader in multidomain Master Data Management (MDM) solutions.” Read the full press release here.
Rob Karel, vice president, Product Strategy and Product Marketing, MDM, Informatica says: “We continue to deliver a multidomain MDM solution that, in combination with Informatica PIM, delivers end-to-end customer, product and supplier information governance and stewardship. Delivering complete, reliable and consistent product information – across every channel – is the key to a great customer experience.” Informatica also kindly provides a free copy of the report. Get the Magic Quadrant for Master Data Management of Product Data Solutions 2014 here.
Data matching has increasingly become a component of Master Data Management (MDM) solutions. This has mostly been the case for MDM of customer data solutions, but it is also a component of MDM of product data solutions not at least when these solutions are emerging into the multi-domain MDM space.
The deployment of data matching was discussed nearly 5 years ago in the post Deploying Data Matching.
While MDM solutions since then have been picking up on the share of the data matching being done around it is still a fairly small proportion of data matching that is performed within MDM solutions. Even if you have a MDM solution with data matching capabilities, you might still consider where data matching should be done. Some considerations I have come across are:
Acquisition and silo consolidation circumstances
A common use case for data matching is as part of an acquisition or internal consolidation of data silos where two or more populations of party master data, product master data and other important entities are to be merged into a single version of truth (or trust) in terms of uniqueness, consistency and other data quality dimensions.
While the MDM hub must be the end goal for storing that truth (or trust) there may be good reasons for doing the data matching before the actual on-boarding of the master data.
The actual matching effectiveness as explored in the post 3 out of 10
The point of entry
The MDM solution isn’t for many good reasons not always the system of entry. To do the data matching at the stage of data being put into the MDM hub may be too late. Expanding the data matching capabilities as Service Oriented Architecture component may be a better way as pondered in the post Service Oriented Data Quality.
The Gartner Magic Quadrant for Master Data Management of Customer Data 2014 is out. One place to get it for free is by using the Informatica registry style page offered in the Informatica communication here.
So, what is good and what is bad when looking for a MDM vendor if you are focusing on customer data right now?
Some words in the strengths assessment of vendors are:
Some words in the cautions assessment of vendors are:
Multi-Domain Master Data Management (MDM) is about dealing with master data in several different data domains as customer (or party), product, location, asset or calendar. The typical track today is starting in one domain. There are many, even contradicting, good reasons for that.
Depending on in what industry vertical you are the main pain points that urges you to start doing MDM belongs to either of the MDM domains. Customer MDM is the most common one typically seen where you have a large number of customer records in your databases. We see starting with product MDM in organizations with many products in the databases. This is for example the case for large retailers and distributors.
It can be other domains as well. One example from a MDM conference I recall is that Royal Mail in the UK started with the calendar domain. Besides that this domain had pain points for that organization a reason to do that was to start small before taking on the big chunks.
Even though you start with one domain, you must think about the end state. One thing to consider multi-domain wise is the data governance part, as you will not come out well if you choose different approaches to data governance for each master data domain. Of course, the technology part is there too. Choosing a solution that eventually will take you all the way is appealing to many organizations looking for a MDM platform.
Another approach to multi-domain MDM can be through what I know at least one MDM tool vendor calls Evolutionary MDM™. But we can call it other things. Agile or lean MDM for example. Using that approach you do not solve everything within one domain before going on to the next one.
It is about eliminating as many pain points as possible in the shortest feasible time-frame.
Back in 2010 I played around with the term Data Quality 3.0. This concept is about how we increasingly use external data within data management opposite to the traditional use of internal data, which are data that has been typed into our databases by employees or has been internally collected in other ways.
The rise of big data has definitely fueled the thinking around using external data as reported in the post Adding 180 Degrees to MDM.
“It’s really fun when the internal components of governance are running smooth, giving the opportunity to focus on external connections to your data governance program. Finding the right balance between internal and external influences is key, as external governance partners can reduce the load/complexity of your overall governance program. It also helps clarify the difference between a “external standard” vs “internal standard”, as well as what is “reference data” vs “master data”… and a little preview of your probable integration strategy with external.”
This resonates very much with my mindset. Since 2010 my own data quality journey has increasingly embraced Master Data Management (MDM) and Data Governance as told in the recent blog post called Data Governance, Data Quality and MDM.
So, in my quest to coin these 3 disciplines into one term I, besides the word information, also may put 3.0 into the naming: “Information Quality 3.0”, hmmm …..
The data governance discipline, the data quality discipline and the Master Data Management (MDM) discipline are closely related and happens to be my fields of work.
Data quality improvement is important within data governance and MDM. Furthermore you seldom see an MDM implementation without a (master) data governance work stream today.
Over time it has often been suggested that data quality should rightfully be named information quality as told in the post New Blog Name. In addition, data governance could be referred to as information governance as suggested in the Mike2 Open Methodology here.
Within MDM we have the term Product Information Management (PIM) which is partly, but maybe not fully, the same as Product MDM, as examined by Monica McDonnell of Informatica in the post PIM is Not Product MDM – Product MDM is not PIM.
Product is one of several domains within MDM, where customer (or rather party), location and asset are other domains going into multi-domain MDM as reported in the post Multi-Entity MDM vs Multidomain MDM.
While replacing the term data with the term information for data quality, data governance and for that matter (multi-domain) master data management has had limited success outside academic circles, I do see it very suitable for being part of a term covering these three disciplines as a whole.
So what should these three disciplines be called as a whole? Have you noticed any good terms or smart hypes out there? Or are they just three out of more disciplines within data or information management?
This product description was nicely fit for the purpose of use when Harrods handled their product data in a material master in an ERP system I guess. But when switching from buy-side focus to sell-side focus in a multi-channel world, this product description gives no meaning to the customer.
Such problems with changing purposes of use for product master data is not only a luxury problem at Harrods but a common challenge within retail and distribution. The challenge involve having customer friendly product descriptions, a range of atomized product attributes that varies by product category and having related digital assets that helps the customer.
Organizations around are, as explained by Andy Hayler, tackling this challenge by implementing Master Data Management (MDM) solutions – in this case those ones specialized in Product Information Management (PIM).
MDM is said to be about a single version of the truth. While this in the customer (or rather party) MDM world is much about achieving uniqueness by matching and merging several different representations of the same real world individual or legal entity, the main challenge in product MDM is a bit different. Here completeness is a big issue. This involves gathering several different pieces of the truth from different sources. And a certain level of completeness may be fit for the purpose of use today but not fit enough tomorrow.
So, how can organizations overcome the huge task of gathering so much product data? I think it is much about Sharing Product Master Data.
How do you select a Master Data Management (MDM) vendor? There is of course the RFP way of scoring vendors against a bunch of carefully specified requirements within data model, user interface, architecture and so on. But as I have seen it, maybe the multi-domain way is much more used.
The multi-domain MDM vendor selection process has three basic parameters:
Distance between locations
Chemistry between parties
Price of products
Distance between locations:
Here you measure four numbers:
N1 = Northern UTM geocode of buyers head quarter
E1 = Eastern UTM geocode of buyers head quarter
N2 = Northern UTM geocode of vendors head quarter or major regional office
E2 = Eastern UTM geocode of vendors head quarter or major regional office
Then using the Pythagorean Theorem you get:
(You could make up the distance on Google Maps as well, but that doesn’t look very scientific).
Chemistry between parties:
Here you, at the meetings between the buying team and the vendor team, measure the occurrence of these sentences:
Could you repeat that question please?
Could you repeat that answer please?
(Observe that there may be a correlation with distance in cases where distance calls for the use of a webex for a meeting).
Price of products:
I guess everyone knows how to sum up euros/dollars/pounds/whatever.
The concept of MDM aware applications have been around for some time. What the Master Data Management establishment, including yours truly, is hoping for, is that applications like CRM, ERP and other systems will start to utilize the master entities in MDM solutions instead of having their own more or less useful data models within data silos around master data entities as parties, products, locations and assets as well as exploiting other good structures and services in the MDM realm.
But what about MDM solutions themselves? Are MDM solutions that smug that they don’t take in good capabilities from other MDM solutions?
One reason to do so is if a MDM vendor have several MDM solutions to offer. An example of that I experienced recently was when attending the Informatica MDM day for EMEA in London the other day. Informatica has recently acquired the Product MDM specialist firm Heiler and has therefore two MDM solutions to offer to the market. It has been too early for the newest version 10 of the general Informatica MDM solution to embrace the Heiler solution, so what I learned from one of the good now Informatica folks was that the Heiler solution is becoming MDM aware – at least aware of the Informatica MDM version 10 solution I guess.
On another front I’m working with the iDQ™ MDM Edition. Here we do have a default data model for party master entities, but we are not that smug that we can’t be aware of other MDM solutions and their capabilities in a given IT landscape. Even in the party domain.