Service Oriented MDM

puzzleMuch 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.

Bookmark and Share

OMG: Santa is Fake

santa facebook picturesThis blog has earlier had some December blog posts about how Santa Claus deals with data quality (Santa Quality) and master data management (Multi-Domain MDM Santa Style).

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?

santa on twitterStarting 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.

Bookmark and Share

Hello Leading MDM Vendor

This morning I received messages from a leading MDM vendor about an upcoming webinar the 12th September.

INFA 01

As we have the 3rd October today this is strange and the vendor of course sent out a correction later today:

INFA 02

That’s OK. Shit happens. Even at data quality and MDM vendors marketing departments.

I am probably a kind of a strange person been living in two countries lately, so I got the original message and the correction both to my Scandinavian identity from the vendor’s Scandinavian body:

INFA 03

As well as to my UK identity from the vendor’s UK body:

INFA 04

That’s OK. Getting a 360 degree view of migrating persons is difficult as discussed in the post 180 Degree Prospective Customer View isn’t Unusual.

Both (double) messages have a salutation.

UK:

INFA 05

Scandinavian:

INFA 06

Being Mr. Sorensen in the UK is OK. Using Mister and surname fits with an English stiff upper lip and The Letter ø could be o in the English alphabet.

I’m not sure if Dear Mr. Sørensen is OK in a Scandinavian context. Hello Henrik would be a better fit.

Bookmark and Share

Will Graph Databases become Common in MDM?

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.

In a comment to the post Five Flavors of Big Data Mike Ferguson asked about graph data quality. In my eyes using graph databases in master data management will indeed bring us closer to the real world and thereby deliver a better data quality for master data.

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.

GraphDatabase_PropertyGraph
Wikiopedia article on graph database

Bookmark and Share

Undertaking in MDM

Pluto's moon CharonIn 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.

Bookmark and Share

Time To Turn Your Customer Master Data Management Social?

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.

Social MDM2Apart 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?

Bookmark and Share

What’s so Special About MDM?

In a blog post from yesterday one of my favorite bloggers Loraine Lawson writes:

“Take master data management, for instance. Oh sure, experts preach that it’s a discipline, not “just” a technology, but come on. Did anybody ever hear about MDM before MDM solutions were created?”

The post is called: Let’s Talk: Do You Really Need an Executive Sponsor for MDM?

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.

shiny thingsI touched this subject some years ago in the post Universal Pearls of Wisdom.

So let’s talk:

  • Is an executive sponsor more important for Master Data Management (MDM) than for Business Intelligence (BI)?
  • Is a business case more important for Master Data Management (MDM) than for Supplier Chain Management (SCM)?
  • Is big bang style more dangerous for Master Data Management (MDM) than for Service Oriented Architecture (SOA)?

And oh, don’t just tell me that I can’t compare apples and pears.

Bookmark and Share

Connecting CRM and MDM with Social Network Profiles

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.

Xing02

Last week I followed a webinar by Dirk Steuernagel of MRM24. It was about connecting your SalesForce.com contact data with Xing.

As said in the MRM24 blog post called Social CRM – Integration von Business Netzwerken in Salesforce.com:

“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).

Xing01

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:

GartnerMDM chat and social MDM

Bookmark and Share

What’s so special about your party master data?

My last blog post was called Is Managing Master Data a Differentiating Capability? The post is an introduction to a conference session being a case story about managing master data at Philips.

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.

business partnersFirst 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 iDQ™ service already fits in at several places as told in the post instant Data Quality and Business Value. I bet it fits your party master data too.

Bookmark and Share

Beyond True Positives in Deduplication

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.

What I like to do when working with getting business value from true positives is to build a so called Hierarchical Single Source of Truth.

Bookmark and Share