Master Data

Another Facet of MDM: Master Relationship Management

Henrik Gabs Liliendahl5 Comments

When talking about Master Data Management (MDM) we deal with something that maybe could be better coined as Master Entity Management. As a good old (logical or not) data model in the relational database world also have relations between entities there must of course then also be something called Master Relationship Management. And indeed there is as mentioned by Aaron Zornes in the interview called MDM and Next-Generation Data Sources on Information Management.

As touched by Aaron Zornes the solution to handling relations in the future may come from outside the relational database world in the form of graph databases. This was also discussed in the post Will Graph Databases become Common in MDM?

An often mentioned driver for looking much more into relationships is the promise of finding customer, and other, insights in social data based on the match between traditional master entity data and social network profiles. Handling these relations is an important facet of social MDM, an often mentioned subject on this blog.

puzzleBuilding the relations doesn’t stop with party master entities. There are valuable relations to location master entities and not at least crucial relations between party master entities and product master entities as told in the post Customer Product Matrix Management.

So Master Relationship Management fits very well with the current main trends in the MDM world being embracing big data not at least social data and encompassing multi-domain MDM. The third main trend being MDM in the cloud also fits. It’s not that we can’t explore all the relations out there from on-premise solutions; it’s just that there is a better relationship in doing so in the cloud.

Bookmark and Share

Why don’t MDM Implementations Stick?

Henrik Gabs Liliendahl5 Comments

puzzleFormer Gartner (the analyst firm) MDM guru John Radcliffe has established his own business and blog and started off revealing some dirty secrets about how sticky MDM implementations are.  Quote:

“Another interesting thing was something that we found during Magic Quadrant reference checking. Increasingly the initial MDM champion, who made the business case, chose the software and led the MDM program had now moved on. The new guy (or gal) in the role often didn’t have the same enthusiasm (putting it politely) for MDM generally, for the MDM software that was installed or for the incumbent MDM software supplier.”

You may read John Radcliffe’s blog here.

A pretty bad review of MDM vendors merits indeed. But, as I have experienced during several decades in the IT business, this is an observation that probably could be made not only in the MDM realm.

However it could be good to learn how MDM implementations could be stickier. What are MDM implementations missing? Is it:

  • The functionality in MDM solutions that needs improvement?
  • The often massive consultancy that comes with a MDM tool that doesn’t meet expectations?
  • Enterprises not actually being ready for MDM?

My take is: All of above in mentioned order. Your take is?

Bookmark and Share

Somehow Deduplication won’t Stick

Henrik Gabs Liliendahl5 Comments

psychographic MDM18 years ago I cruised into the data quality realm when making my first deduplication tool. Then it was an attempt to solve a business case of two companies who were considering merging and wanted to know the intersection of customers. So far, so good.

Since then I have worked intensively with deduplication and other data matching tools and approaches and also co-authored a leading eLearning course on the matter as seen here.

Deduplication capability is a core feature of many data quality tools and indeed the probably most mentioned data quality pain is lack of uniqueness not at least in party master data management.

However, most deduplication efforts don’t in my experience stick. Yes, we can process a file ready for direct marketing and purge the messages that might end up in the same offline or online inbox despite of spelling differences. But taking it from there and use the techniques in achieving a single customer view is another story. Some obstacles are:

In the comments to the latter 3 year old post the intersection (and non-intersection) of Entity Resolution and Master Data Management (MDM) was discussed.

During my latest work I have become more and more convinced that achieving a single view of something is a lot about entity resolution as expressed in the post The Good, Better and Best Way of Avoiding Duplicates.

Bookmark and Share

Will Graph Databases become Common in MDM?

Henrik Gabs Liliendahl8 Comments

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

Henrik Gabs Liliendahl3 Comments

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

The Relocation Event

Henrik Gabs Liliendahl7 Comments

relocationWhen maintaining party master data one of the challenges is to have the data about the physical address, and sometimes the physical addresses, of a registered party up to date.

You may learn about that your customer, supplier, employee or whatever party you are keeping on record has moved in many ways. Most common are:

  • The person or organization in question is so kind to tell you so. For some purposes for example in the utility sector this event is a future event that triggers a whole workflow of actions.
  • You get the message via a subscription to external reference data for example using available National Change of Address (NCOA) services and services related to business directories and citizen registries.
  • Your mail to a person or organization is returned from postal services often with no information about the new address, so this means investigation work ahead.

Capability to handle this important issue in party master data management (MDM) embracing all the above mentioned scenarios is essential for many enterprises and doing it on an international scale with the different sources and services available in different countries is indeed a daunting task.

Handling the relocation event is a core functionality in the master data service (iDQ™ MDM Edition) I’m currently working with. There’s lot to do in this quest, so I better move on.

Bookmark and Share

MDM is all about Software Brands

Henrik Gabs Liliendahl8 Comments

LinkedIn is a great social service for professionals. I often read descriptions of LinkedIn with the sentiment that LinkedIn is a recruitment platform. However, in my opinion LinkedIn is much more than that. To me LinkedIn is more about networking, knowledge sharing, social marketing and social selling.

But that said, recruiters are certainly very active on LinkedIn. I guess it happens to me every week that I’m contacted on LinkedIn by a recruiter with a MDM (Master Data Management) job.

MDM BrandsThe opening is practically always like this:

“We are looking for a candidate with experience with <brand>….”, where <brand> is Informatica, Oracle, IBM, SAP and other well known brands in the MDM sphere.

As I don’t guess the recruiters make up the top requirement themselves, this number one requirement probably comes from the hiring organization. So to users of MDM, MDM is all about the software brand. Never mind people and processes. That’s easy. Technology is the hard part, not at least mastering the master data technology that was bought after a thorough selection process.

Bookmark and Share

Matching for Multiple Purposes

Henrik Gabs Liliendahl2 Comments

In a recent post on the InfoTrellis blog we have the good old question in data matching about Deterministic Matching versus Probabilistic Matching.

The post has a good walk through on the topic and reaches this conclusion:

“So, which is better, Deterministic Matching or Probabilistic Matching?  The question should actually be: ‘Which is better for you, for your specific needs?’  Your specific needs may even call for a combination of the two methodologies instead of going purely with one.”

On a side note the author of the post is MARIANITORRALBA. I had to use my combined probabilistic and deterministic in-word parsing supported and social media connected data matching capability to match this concatenated name with the Linked profile of an InfoTrellis employee called Marian Itorralba.

This little exercise brings me to an observation about data matching that is, that matching party master data, not at least when you do this for several purposes, ultimately is identity resolution as discussed in the post The New Year in Identity Resolution.

HierarchyFor that we need what could be called hierarchical data matching.

The reason we need hierarchical data matching is that more and more organizations are looking into master data management and then they realize that the classic name and address matching rules do not necessarily fit when party master data are going to be used for multiple purposes. What constitutes a duplicate in one context, like sending a direct mail, doesn’t necessary make a duplicate in another business function and vice versa. Duplicates come in hierarchies.

One example is a household. You probably don’t want to send two sets of the same material to a household, but you might want to engage in a 1-to-1 dialogue with the individual members. Another example is that you might do some very different kinds of business with the same legal entity. Financial risk management is the same, but different sales or purchase processes may require very different views.

This matter is discussed in the post and not at least the comments of the post called Hierarchical Data Matching.

Bookmark and Share

Time to Turn Your Product Master Data Management Social?

Henrik Gabs Liliendahl2 Comments

Yesterday’s post on this blog had the title Time To Turn Your Customer Master Data Management Social? In a true Multi-Domain MDM spirit it is of course also timely to ask if it is time to turn your product master data management social.

Social PIMHere are a few ways to go when thinking social into product master data management:

Making product data lively

Kimmo Kontra had a blog post called With Tiger’s clubs, you’ll golf better – and what it means to Product Information Management. Herein Kimmo examined how stories around products help with selling products. Kimmo concluded that within master data management there is going to be a need for storing and managing stories.

So while traditional product master data management is about having the right hard facts about products consistent across multiple channels, and having the right images and other rich media consistent as well, in the social era you will also need to include the right and consistent stories when the multiple channels embraces social media.

Sharing product data

How do we ensure that we share the same product information, including the same stories, across the ecosystem of product manufacturers, distributors, retailers and end users?

During recent times I have followed a new cloud service called Actualog. Actualog is aiming at doing exactly that with emphasis on the daunting task of sharing product data in an international environment with different measurement systems, languages, alphabets and script systems.

Listening to big data

As discussed in the post Big Data and Multi Domain Master Data Management a prerequisite for getting sense out of analyzing social data (and other big data sources) is, that you not only have a consistent view of the product data related to products that you sell yourself, but also have a consistent view of competing products and how they relate to your products.

Therefore social product master data management requires you to extend the volume of products handled by your product information management solution probably in alternate product hierarchies.

Bookmark and Share

Time To Turn Your Customer Master Data Management Social?

Henrik Gabs LiliendahlLeave a comment

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