Master Data Management (MDM) is increasingly being about supporting systems of engagement in addition to the traditional role of supporting systems of record. This topic was first examined on this blog back in 2012 in the post called Social MDM and Systems of Engagement.
The best known systems of engagement are social networks where the leaders are Facebook for engagement with persons in the private sphere and LinkedIn for engagement with people working in or for one or several companies.
But what about engagement between companies? Though you can argue that all (soft) engagement is neither business-to-consumer (B2C) nor business-to-business (B2B) but human-to-human (H2H), there are some hard engagement going on between companies.
One of the most important ones is exchange of product information between manufacturers, distributors, resellers and large end users of product information. And that is not going very well today. Either it is based on fluffy emailing of spreadsheets or using rigid data pools and portals. So there are definitely room for improvement here.
In my eyes, this trend will have a huge impact on how data management platforms should be delivered in the future. Until now much of the methodology and technology for data management platforms have been limited to how these things are handled within the corporate walls. We will need a new breed of data management platforms build for business ecosystems.
Such platforms will have the characteristics of other new approaches to handling data. They will resemble social networks where you request and accept connections. They will embrace data as big data and data lakes, where every purpose of data consumption are not cut in stone before collecting data. These platforms will predominately be based in the cloud.
Right now I am working with putting such a data management service up in the cloud. The aim is to support product data sharing for business ecosystems. I will welcome you, and your trading partners, as subscriber to the service. If you help trading partners with Product Information Management (PIM) there is a place for you as ambassador. Anyway, please start with following Product Data Lake on LinkedIn.
“I’d like to hear back from anyone who has implemented party master data in either a single, unified schema or separate, individual schemas (Vendor, Customer, etc.).
What were the pros and cons of your approach? Would you do it the same way if you had it to do again?”
This is a classic consideration at the heart of multi-domain MDM. As I see it, and what I advise my clients to do, is to have a common party (or business partner) structure for identification, names, addresses and contact data. This should be supported by data quality capabilities strongly build on external reference data (third party data). Besides this common structure, there should be specific structures for customer, vendor/supplier and other party roles.
This subject was also recently examined here on the blog in the post Multi-Side MDM.
A recent post on this blog was called Three Stages of MDM Maturity. This post ponders the need to extend your Master Data Management (MDM) solution to external business partners and take more advantage of third party data providers. We may call this MDM 3.0.
In a comment on LinkedIn Bernard PERRINEAU says:
Starting with the most often mentioned point against extending your MDM solution to the outside Vipul Aroh of Verdantis rightfully in a comment to the post mentions a wide spread hesitancy around. I think/hope this hesitancy is the same as the hesitancy we saw when Salesforce.com first emerged. Many people didn’t foresee a great future for Salesforce.com, because putting your customer base into the cloud was seen as a huge risk. But eventually the operational advantages in most cases have trumped the thought risks.
Ironically the existents of CRM systems, in the cloud or not, is a hindrance for MDM solutions to be system of entry or support data entry for the customer master data domain. I remember when talking to a MDM vendor CEO about putting such features for customer data entry into a MDM solution his reply was something like: “Clients don’t want that, they want to consolidate downstream”. I think it is a pity that “clients want” to automate the mess and that MDM and other vendors wants to help them with that.
That said, there are IT system landscape circumstances to be overcome in order to put your MDM solution to the forefront.
But when doing that, and even when starting to do that, the advantages are plentiful. A story about a start of such a journey for customer master data is shared in the post instant Data Quality at Work. This approach is examined more in the post instant Single Customer View. To summarize you will gain both on getting data quality right the first time and at the same time save time (and time is money) in the data collection stage.
When it comes to product master data I think everyone working in that field acknowledges the insanity in how the same data are retyped, or messed around in spreadsheets, between manufactures, distributors, retailers and end users. Some approaches to overcome this are explored in the post Sharing Product Master Data. Each of these approaches has their pros and cons.
The rise of big data also points in the direction of having your MDM solution exposed to the outside as touched in the post Adding 180 Degrees to MDM.
A frequent update on my LinkedIn home page these days is about the HiPPO principle. The HiPPO principle is used to describe a leadership style based on priority for the leader’s opinion opposite to using data as explained in the Forbes article here.
The hippo (hippopotamus) is one of largest animals on this planet. So is the rhino (rhinoceros). The rhino is critically endangered because it is hunted by humans due to a very little part of its body, being the horn.
I guess anyone who has been in business for some years has met the hippo. Probably you also have experienced a rhino hunt being a project or programme of very big size but aiming at a quite narrow business objective that may have been expressed as a simple slogan by a hippo.
Identity resolution is a hot potato when we look into how we can exploit big data and within that frame not at least social data.
Some of the most frequent mentioned use cases for big data analytics revolves around listening to social data streams and combine that with traditional sources within customer intelligence. In order to do that we need to know about who is talking out there and that must be done by using identity resolution features encompassing social networks.
The second challenge is what we are allowed to do. Social networks have a natural interest in protecting member’s privacy besides they also have a commercial interest in doing so. The degree of privacy protection varies between social networks. Twitter is quite open but on the other hand holds very little usable stuff for identity resolution as well as sense making from the streams is an issue. Networks as Facebook and LinkedIn are, for good reasons, not so easy to exploit due to the (chancing) game rules applied.