Much of the talking and doing related to Master Data Management (MDM) today revolves around the master data repository being the central data store for information about customers, suppliers and other parties, products, locations, assets and what else are regarded as master data entities.
The difficulties in MDM implementations are often experienced because master data are born, maintained and consumed in a range of applications as ERP systems, CRM solutions and heaps of specialized applications.
It would be nice if these applications were MDM aware. But usually they are not.
As discussed in the post Service Oriented Data Quality the concepts of Service Oriented Architecture (SOA) makes a lot of sense in deploying data quality tool capacities that goes beyond the classic batch cleansing approach.
In the same way, we also need SOA thinking when we have to make the master data repository doing useful stuff all over the scattered application landscape that most organizations live with today and probably will in the future.
MDM functionality deployed as SOA components have a lot to offer, as for example:
Reuse is one of the core principles of SOA. Having the same master data quality rules applied to every entry point of the same sort of master data will help with consistency.
Interoperability will make it possible to deploy master data quality prevention as close to the root as possible.
Composability makes it possible to combine functionality with different advantages – e.g. combining internal master data lookup with external reference data lookup.
As I like to be on the top of the hype curve I was preparing a post about how Santa digs into big data, including social data streams, to be better at finding out who is nice and who is naughty and what they really want for Christmas. But then I suddenly had a light bulb moment saying: Wait, why don’t you take your own medicine and look up who that Santa guy really is?
Starting in social media checking twitter accounts was shocking. All profiles are fake. FaceBook, Linkedin and other social networks all turned out having no real Santa Claus. Going to commercial third party directories and open government data had the same result. No real Santa Claus there. Some address directories had a postal code with a relation like the postcode “H0 H0 H0” in Canada and “SAN TA1” in the UK, but they seem to kind of fake too.
So, shifting from relying on the purpose of use to real world alignment I have concluded that Santa Claus doesn’t exist and therefore he can’t have a data store looking like a toy elephant or any other big data operations going on.
Also I won’t, based on the above instant data quality mash up, register Santa Claus (Inc.) as a prospective customer in my CRM system. Sorry.
One of my pet peeves in data quality for CRM and ERP systems is the often used way at looking at entities, not at least party entities, in a flat data model as told in the post A Place in Time.
Party master data, and related location master data, will eventually be modeled in very complex models and surely we see more and more examples of that. For example I remember that I long time ago worked with the ERP system that later became Microsoft Dynamics AX. Then I had issues with the simplistic and not role aware data model. While I’m currently working in a project using the AX 2012 Address Book it’s good to see that things have certainly developed.
This blog has quite a few posts on hierarchy management in Master Data Management (MDM) and even Hierarchical Data Matching. But I have to admit that even complex relational data models and hierarchical approaches in fact don’t align completely with the real world.
I remember at this year’s MDM Summit Europe that Aaron Zornes suggested that a graph database will be the best choice for reflecting the most basic reference dataset being The Country List. Oh yes, and in master data too you should think then, though I doubt that the relational database and hierarchy management will be out of fashion for a while.
So it could be good to know if you have seen or worked with graph databases in master data management beyond representing a static analysis result as a graph database.
In the post Last Time Right the bad consequences of not handling that one of your customers aren’t among us anymore was touched.
This sad event is a major trigger in party master data lifecycle management like The Relocation Event I described last week.
In the data quality realm handling so called deceased data has been much about suppression services in direct marketing. But as we develop more advanced master data services handling the many aspects of the deceased event turns up as an important capability.
Like with relocation you may learn about the sad event in several ways:
A message from relatives
Subscription to external reference data services, which will be different from country to country
Investigation upon returned mail via postal services
Apart from in Business-to-Consumer (B2C) activities the deceased event also has relevance in Business-to-Business (B2B) where we may call it the dissolved event.
One benefit of having a central master data management functionality is that every party role and related business processes can be notified about the status which may trigger a workflow.
An area where I have worked with handling this situation was in public transit where subscription services for public transport is cancelled when learning about a decease thus lifting some burden on relatives and also avoiding processes for paying back money in this situation.
Right now I’m working with data stewardship functionality in the instant Data Quality MDM Edition where the relocation event, the deceased event and other important events in party master data lifecycle management must be supported by functionality embracing external reference data and internal master data.
The title of a post on the Nimble blog has this question: Time To Turn Your Sales Team Social?´ The post has a lot of evidence on why sales teams that embrace social selling are doing better than teams that doesn’t do that.
We do see new applications supporting social selling where Nimble is one example from the Customer Relationship Management (CRM) sphere as explored in the post Sharing Social Master Data. Using social services and exploiting social data in sales related business processes will over time affect the way we are doing customer master data management.
Apart from having frontend applications being social aware we also need social aware data integration services and we do indeed need social aware Master Data Management (MDM) solutions for handling data quality issues and ensuring a Single Customer View (SCV) stretching from the old systems of record to the new systems of engagement.
One service capable of doing data integration between the old world and the new world is FlipTop and some months ago I was interviewed on the FlipTop blog about the links to Social MDM here. Currently I’m working with a social aware Master Data Management solution being the iDQ™ MDM Edition.
What about you? Are your Customer Master Data Management and related data quality activities becoming social aware?
And yes we do need an executive sponsor. Also we need a business case as we must avoid doing it big bang style and we need to establish metrics for measuring success and so on.
All wise things as it is wise sayings about data quality improvement initiatives, business intelligence (BI) implementations, customer relationship management (CRM) system roll-out and almost any other kind of technology enabled project.
As told on DataQualityPro recently in an interview post about the Benefits of Social MDM, doing social MDM (Master Data Management) may still be outside the radar of most MDM implementations. But there are plenty of things happening with connecting CRM (Customer Relationship Management) and social engagement.
While a lot of the talk is about the biggest social networks as FaceBook and LinkedIn, there are also things going around with more local social networks like the German alternative to LinkedIn called Xing.
Last week I followed a webinar by Dirk Steuernagel of MRM24. It was about connecting your SalesForce.com contact data with Xing.
“Our business contacts are usually found in various internal and external systems and on non-synchronized platforms. It requires a lot of effort and nerves to maintain all of our business contacts at the different locations and keep the relevant information up to date.”
(Translated to English by Google and me).
We see a lot of connectors between CRM systems and social networks.
In due time we will also see a lot of connectors between MDM and social networks, which is a natural consequence of the spread of social CRM. This trend was also strongly emphasized on the Gartner (the analyst firm) tweet chat today:
During my years working with data quality and master data management it has always struck me how different organizations are managing the party master data domain while in fact the issues are almost the same everywhere.
First of all party master data are describing real world entities being the same to everyone. Everyone is gathering data about the same individuals and the same companies being on the same addresses and having the same digital identities. The real world also comes in hierarchies as households, company families and contacts belonging to companies which are the same to everyone. We may call that the external hierarchy.
Based on that everyone has some kind of demand for intended duplicates as a given individual or company may have several accounts for specific purposes and roles. We may call that the internal hierarchy.
A party master data solution will optimally reflect the internal hierarchy while most of the business processes around are supported by CRM-systems, ERP-systems and special solutions for each industry.
Fulfilling reflecting the external hierarchy will be the same to everyone and there is no need for anyone to reinvent the wheel here. There are already plenty of data models, data services and data sources out there.
Right now I’m working on a service called instant Data Quality that is capable of embracing and mashing up external reference data sources for addresses, properties, companies and individuals from all over the world.
The most frequent data quality improvement process done around is deduplication of party master data.
A core functionality of many data quality tools is the capability to find duplicates in large datasets with names, addresses and other party identification data.
When evaluating the result of such a process we usually divide the result of found duplicates into:
False positives being automated match results that actually do not reflect real world duplicates
True positives being automated match results reflecting the same real world entity
The difficulties in reaching the above result aside, you should think the rest is easy. Take the true positives, merge into a golden record and purge the unneeded duplicate records in your database.
Well, I have seen so many well executed deduplication jobs ending just there, because there are a lot of reasons for not making the golden records.
Sure, at lot of duplicates “are bad” and should be eliminated.
But many duplicates “are good” and have actually been put into the databases for a good reason supporting different kind of business processes where one view is needed in one case and another view is needed in another case.
Many, many operational applications, including very popular ERP and CRM systems, do have inferior data models that are not able to reflect the complexity of the real world.
Only a handful of MDM (Master Data Management) solutions are able to do so, but even then the solutions aren’t easy as most enterprises have an IT landscape with all kinds of applications with other business relevant functionality that isn’t replaced by a MDM solution.