Slicing the MDM Space

Master DataThese days I am attending the Gartner MDM summit in London.

MDM (Master Data Management) initiatives and MDM solutions are not created equal and different ways of slicing the MDM world were put forward on the first day.

Gartner is famous for the magic quadrants and during the customer master data quadrant presentation I heard Bill O’Kane explain why this is a separate quadrant from the product master data quadrant and why there are no challengers and no visionaries.

In another session about MDM milestones Bill O’Kane for this context sliced the MDM world a bit differently based on moving between MDM styles. Here we had:

  • Business-to-consumer (B2C) Customer Data Integration (CDI)
  • Business-to-business (B2B) customer MDM, Product Information Management (PIM) and other domains.

The vendors in general seems to want to do everything MDM.

Stibo Systems, a traditional PIM vendor, presented the case for multidomain MDM based on how things have developed within eCommerce. Stibo even smuggled the term omnidomain MDM into the slides. A marketing gig in the making perhaps.

The megavendors has bought who ever they need to be multidomain.

Some new solutions are born in the multidomain age. Semarchy is an interesting example as they are so the evolutionary way.

Bookmark and Share

Data Entry by Employees

A recent infographic prepared by Trillium Software highlights a fact about data quality I personally have been preaching about a lot:

Trillium 75 percent

This number is (roughly) sourced from a study by Wayne W. Eckerson of The Data Warehouse Institute made in 2002:

TDWI 76 percent

So, in the fight against bad data quality, a good place to start will be helping data entry personnel doing it right the first time.

One way of achieving that is to cut down on the data being entered. This may be done by picking the data from sources already available out there instead of retyping things and making those annoying flaws.

If we look at the two most prominent master data domains, some ideas will be:

  • In the product domain I have seen my share of product descriptions and specifications being reentered when flowing down in the supply chain of manufacturers, distributors, re-sellers, retailers and end users. Better batch interfaces with data quality controls is one way of coping with that. Social collaboration is another one as told in the post Social PIM.
  • In the customer, or rather party, domain we have seen an uptake of using address validation. That is good. However, it is not good enough as discussed in the post Beyond Address Validation.

Bookmark and Share

Third-Party Data and MDM

A recent blog post called Top 14 Master Data Management Misconceptions by William McKnight has as the last misconception this one:

“14. Third-party data is inappropriate for MDM

Third-party data is largely about extending the profile of important subject areas, which are mastered in MDM.  Taking third-party data into organizations has actually kicked off many MDM programs.”

business partnersIndeed, using third-party data, which also could be called big external reference data, is in my eyes a very good solution for a lot of use cases. Some of the most popular exploitations today are:

  • Using a business directory as big reference data for B2B party master data in customer data integration (CDI) and supplier master data management.
  • Using address directories as big reference data for location master data management also related to party master data management for B2C customer data.
  • Using product data directories such as the Global data Synchronization Network (GDSN®) services, the UNSPSC® directory and heaps of industry specific product directories.

The next wave of exploiting external data, which is just kicking off as Social MDM, is digging into social media for sharing data, including:

  • Using professional social networks as LinkedIn in B2B environments where you often find the most timely reference data not at least about contact data related to your business partners’ accounts.
  • Using consumer oriented social networks as Facebook for getting to know your B2C customers better.
  • Using social collaboration as a way to achieve better product master data as told in the post Social PIM.

Bookmark and Share

Multi-Facet MDM

In MDM (Master Data Management) there is the term Multi-Domain MDM being how we manage respectively parties, products, locations and other entity types and handling master data within a Multi-Channel environment encompassing offline, online and social channels is a huge challenge within MDM today. Yet another multi view of MDM is handling different facets of master data being:

  • Mulit-Facet MDMEntities
  • Relations
  • Events

Entities

Handling entities is the core of master data management. Ensuring that master data are fit for multiple purposes most often by ensuring real world alignment is the basic goal of master data management. Entity resolution is at key discipline in doing that. In the party master data domain doing Customer Data Integration (CDI) is the good old activity aiming at compiling all the customer data silos in the enterprise into a golden copy with golden records. Product Information Management (PIM) is another ancestor in the MDM evolution history predominately focusing at the entities.

Relations

A possible distinction between Master Entity Management and Master Relation Management is discussed in the post Another Facet of MDM: Master Relationship Management.

As we get better and better solutions for handling entities the innovation shifts to handling the relationships between entities. These relations exists for example in Multi-Channel environments by linking entities in the old systems of record with the same real world entities in the new systems of engagement as told in the post Social MDM and Systems of Engagement.

Events

Getting the master data right the first time is crucial.

In product master data management getting to that stage is often done by managing a flow of events where the product data are completed and approved by a team of knowledge workers.

In party master data management a way of ensuring first time right is examined in the post instant Single Customer View. But that is only the start. Party master data has a life cycle with important events as:

Bookmark and Share

The MDM Landscape is Slowly Changing

This year’s version of the MDM (Master Data Management) Landscape report from Information Difference is out.

The report confirms some trends in MDM offerings also mentioned here on the blog. Some sayings from the Information Difference report are:

  • “The market is starting to dabble in cloud-based implementations…”
  • “There continues to be a demand for MDM offerings to handle reference data….”
  • “ …still very much in their early stages, are support for Big Data…”

Categorizing the vendors into the traditional division of Customer Data Integration (CDI) versus Product Information Management (PIM) support is becoming less relevant as new Multi-Domain offerings are coming out and larger Product Master Data specialists as Hybris and Heiler has been snapped by megavendors. This leaves Stibo as the only remaining large PIM vendor, but Stibo has actually already rebranded themselves as a Multi-Domain player and have been working seriously on that for a couple of years.

MDM 2013You may view the full Information Difference MDM Landscape report here.

Bookmark and Share

Multi-Entity MDM vs Multidomain MDM

puzzleOn the upcoming MDM Summit Europe 2013 in London this April you will be able to learn about Multi-Entity MDM as well as Multi-Domain MDM.

So, what is the difference between Multi-Entity MDM and Multi-Domain MDM?

To my knowledge it is two terms having the same meaning. It is doing the two main preceding disciplines for MDM being Customer Data Integration (CDI) and Product Information Management (PIM) at the same time presumably using the same software brand.

Multi-Entity MDM was probably the first term used and still used by The MDM Institute while Multidomain MDM is used by Gartner (the analyst firm) and most tool vendors today. For example Stibo Systems is focusing on mutidomain recently in this press release about latest achievements.

Talking about Gartner and the vendor crowd Gartner analyst Andrew White wrote a blog post the other day: Round-Up of Master Data Management (MDM) 2012, and looking forward to 2013.

Herein White bashes the vendors by saying:

“Vendor hype related to multidomain …. continued to be far in excess of reality”.

What do you think? Is Andrew White right about that? And what about Multi-Entity MDM, is that any better?

Bookmark and Share

Doing MDM in the Cloud

As reported in the post What to do in 2012 doing Master Data Management (MDM) in the cloud is one of three trends within MDM that according to Gartner (the analyst firm) will shape the MDM market in the coming years.

Doing MDM in the cloud is an obvious choice if all your operational applications are in the cloud already. Such a solution was presented on Informatica Perspectives in the blog post Power the Social Enterprise with a Complete Customer View. The post includes a Video where the situation with multiple instances of SalesForce.com solutions within the same enterprise is supported by a master data backbone in the cloud.

But even if all your operational applications are on premise you may start with lifting some master data management functionality up in the cloud. I am currently working with such a solution.

When onboarding customer (and other party) master data much of the basic information needed is already known in the cloud. Therefore lifting the onboarding functionality up into the cloud makes a lot of sense. This is the premise, so to speak, for the MDM edition of the instant Data Quality (iDQ) solution that we are working on these days.

Cloud services for the other prominent MDM domain being product master data also makes a lot of sense. As told in the post Social PIM a lot of basic product master data may be shared in the cloud embracing the supply chain of manufacturers, distributors, retailers and end users.

In both these cases some of the master data management functionality is handled in the cloud while the data integration stuff takes place where the operational applications resides be that in the cloud and/or on premise.

Bookmark and Share

Killing Keystrokes

Keystrokes are evil. Every keystroke represents a potential root cause of poor data quality by spelling things wrongly, putting the right thing in the wrong place, putting the wrong thing in the right place and so on. Besides that every keystroke is a cost of work summing up with all the other keystrokes to gigantic amounts of work costs.

In master data management (MDM) you will be able to getting things right, and reduce working costs, by killing keystrokes wherever possible.

Killing keystrokes in Product Information Management (PIM)

I have seen my share of current business processes where product master data are reentered or copied and pasted from different sources extracted from one product master data container and, often via spreadsheets, captured into another product master data container.

This happens inside organizations and it happens in the ecosystem of business partners in supply chains encompassing manufactures, distributors and retailers.

As touched in the post Social PIM there might be light at the end of the tunnel by the rise of tools, services and platforms setting up collaboration possibilities for sharing product master data and thus avoiding those evil keystrokes.

Killing keystrokes in Party Master Data Management

With party master data there are good possibilities of exploiting external data from big reference data sources and thus avoiding the evil keystrokes. The post instant Data Quality at Work tells about how a large utility company have gained better data quality, and reduced working costs, by using the iDQ™ service in that way within customer on-boarding and other business processes related to customer master data maintenance.

The next big thing in this area will be the customer data integration (CDI) part of what I call Social MDM, where you may avoid the evil keystrokes by utilizing the keystrokes already made in social networks by who the master data is about.

Bookmark and Share

Social Commerce and Multi-Domain MDM

The term social commerce is said to be a subset of eCommerce where social media is used to ultimately drag prospects and returning customers to your website, where a purchase of products and services can be made.

In complex sales processes, typically for Business-to-Business (B2B) sales, the website may offer product information sheets, demo requests, contact forms and other pipeline steps.

This is the moment where your social media engaged (prospective) customer meets your master data as:

  • The (prospective) customer creates and maintains name, address and communication information by using registration functions
  • The (prospective) customer searches for and reads product information on web shops and information sites

One aspect of this transition is how master data is carried over, namely:

  • How the social network profile used in engagement is captured as part of (prospective) customer master data or if it should be part of master data at all?
  • How product information from the governed master data hub has been used as part of the social media engagement or if the data governance of product data should be extended to use in social media at all?

Any thoughts?

Bookmark and Share

The Database versus the Hub

In the LinkedIn Multi-Domain MDM group we have an ongoing discussion about why you need a master data hub when you already got some workflow, UI and a database.

I have been involved in several master data quality improvement programs without having the opportunity of storing the results in a genuine MDM solution, for example as described in the post Lean MDM. And of course this may very well result in a success story.

However there are some architectural reasons why many more organizations than those who are using a MDM hub today may find benefits in sooner or later having a Master Data hub.

Hierarchical Completeness

If we start with product master data the main issue with storing product master data is the diversity in the requirements for which attributes is needed and when they are needed dependent on the categorization of the products involved.

Typical you will have hundreds or thousands of different attributes where some are crucial for one kind of product and absolutely ridiculous for another kind of product.

Modeling a single product table with thousands of attributes is not a good database practice and pre-modeling tables for each thought categorization is very inflexible.

Setting up mandatory fields on database level for product master data tables is asking for data quality issues as you can’t miss either over-killing or under-killing.

Also product master data entities are seldom created in one single insertion, but is inserted and updated by several different employees each responsible for a set of attributes until it is ready to be approved as a whole.

A master data hub, not at least those born in the product domain, is built for those realities.

The party domain has hierarchical issues too. One example will be if a state/province is mandatory on an address, which is dependent on the country in question.

Single Business Partner View

I like the term “single business partner view” as a higher vision for the more common “single customer view”, as we have the same architectural requirements for supplier master data, employee master data and other master data concerning business partners as we have for the of course extremely important customer master data.

The uniqueness dimension of data quality has a really hard time in common database managers. Having duplicate customer, supplier and employee master data records is the most frequent data quality issue around.

In this sense, a duplicate party is not a record with accurately the same fields filled and with accurate the same values spelled accurately the same as a database will see it. A duplicate is one record reflecting the same real world entity as another record and a duplicate group is more records reflecting the same real world entity.

Even though some database managers have fuzzy capabilities they are still very inadequate in finding these duplicates based on including several attributes at one time and not at least finding duplicate groups.

Finding duplicates when inserting supposed new entities into your customer list and other party master data containers is only the first challenge concerning uniqueness. Next you have to solve the so called survivorship questions being what values will survive unavoidable differences.

Finally the results to be stored may have several constructing outcomes. Maybe a new insertion must be split into two entities belonging to two different hierarchy levels in your party master data universe.

A master data hub will have the capabilities to solve this complexity, some for customer master data only, some also for supplier master data combined with similar challenges with product master data and eventually also other party master data.

Domain Real World Awareness

Building hierarchies, filling incomplete attributes and consolidating duplicates and other forms of real world alignment is most often fulfilled by including external reference data.

There are many sources available for party master as address directories, business directories and citizen information dependent on countries in question.

With product master data global data synchronization involving common product identifiers and product classifications is becoming very important when doing business the lean way.

Master data hubs knows these sources of external reference data so you, once again, don’t have to reinvent the wheel.

Bookmark and Share