MDM

Three Stages of MDM Maturity

Henrik Gabs Liliendahl6 Comments

If you haven’t yet implemented a Master Data Management (MDM) solution you typically holds master data in dedicated solutions for Supply Chain Management (SCM), Enterprise Resource Planning (ERP), Customer Relation Management (CRM) and heaps of other solutions aimed at taking care of some part of your business depending on your particular industry.

MDM Stage 1
Multiple sources of truth

In this first stage some master data flows into these solutions from business partners in different ways, flows around between the solutions inside your IT landscape and flows out to business partners directly from the various solutions.

The big pain in this stage is that a given real world entity may be described very different when coming in, when used inside your IT landscape and when presented by you to the outside. Additionally it is hard to measure and improve data quality and there may be several different business processes doing the same thing in an alternative way.

The answer today is to implement a Master Data Management (MDM) solution. When doing that you in some degree may rearrange the way master data flows into your IT landscape, you move the emphasis on master data management from the SCM, ERP, CRM and other solutions to the MDM platform and orchestrate the internal flows differently and you are most often able to present a given real world entity in a consistent way to the outside.

MDM Stage 2
Striving for a single source of truth

In this second stage you have cured the pain of inconsistent presentation of a given real world entity and as a result of that you are in a much better position to measure and control data quality. But typically you haven’t gained much in operational efficiency.

You need to enter a third stage. MDM 3.0 so to speak. In this stage you extend your MDM solution to your business partners and take much more advantage of third party data providers.

MDM Stage 3
Single place of trust

The master data kept by any organization is in a large degree a description of real world entities that also is digitalized by business partners and third party data providers. Therefore there are huge opportunities for reengineering your business processes for master data collection and interactive sharing of master data with mutual benefits for you and your business partners. These opportunities are touched in the post MDM 3.0 Musings.

Bookmark and Share

Automate or Obliterate, That is the Question

Henrik Gabs Liliendahl4 Comments

Back in 1990 Michael Hammer made a famous article called Reengineering Work: Don’t Automate, Obliterate.

Indeed, while automation is a most wanted outcome of Master Data Management (MDM) implementations and many other IT enabled initiatives, you should always consider the alternative being eliminating (or simplifying). This often means thinking out of the box.

As an example I today stumbled upon the Wikipedia explanation about Business Process Mapping. The example used is how to make breakfast (the food part):

Makebreakfast

You could think about different Business Process Re-engineering opportunities for that process. But you could also realize that this is an English / American breakfast. What about making a French breakfast instead. Will be as simple as:

Input money > Buy croissant > Fait accompli

PS: From the data quality and MDM world one example of making French breakfast instead of English / American breakfast is examined in the post The Good, Better and Best Way of Avoiding Duplicates.

Bookmark and Share

To-Be Business Rules and MDM

Henrik Gabs LiliendahlLeave a comment

checklistAn important part of implementing Master Data Management (MDM) is to capture the business rules that exists within the implementing organization and build those rules into the solution. In addition, and maybe even more important, is the quest of crafting new business rules that helps making master data being of more value to the implementing organization.

Examples of such new business rules that may come along with MDM implementations are:

  • In order to open a business account you must supply a valid Legal Entity Identifier (like Company Registration Number, VAT number or whatever applies to the business and geography in question)
  • A delivery address must be verified against an address directory (valid for the geography in question)
  • In order to bring a product into business there is a minimum requirement for completeness of product information.

Creating new business rules to be part of the to-be master data regime highlights the interdependency of people, process and technology. New technology can often be the driver for taking on board such new business rules. Building on the above examples such possibilities may be:

  • The ability to support real time pick and check of external identifiers
  • The ability to support real time auto completion and check of postal addresses
  • The ability to support complex completeness checks of a range of data elements

Bookmark and Share

MDM 3.0 Musings

Henrik Gabs LiliendahlLeave a comment

The term Data Quality 3.0 has been around on this blog for nearly 5 years and was recently aired again in the post Data Quality 3.0 Revisited.

A natural consequence of the concept of Data Quality 3.0 is something we may call Master Data Management (MDM) 3.0.

Master Data Management has in a large degree until now been about how to manage master data internally within organizations. The goal has often been to merge different data silos within the organization into one trusted source of master data. But any organization in itself manages a master data silo too. The master data kept by any organization is in a large degree a description of real world entities that also is digitalized by business partners and other third party entities.

The possibility of sharing customer, or rather party, master data as well as product and location master data was examined in the post Third Party Data and MDM.

open-doorBut how do popular MDM solutions facilitate the enormous potential of looking outside the implementing organization when it comes to achieving high value master data? Very poor, in general, I’m afraid. From my experience MDM vendors stops at the point of creating more or less readymade interfaces to popular data pools and for product data some kind of supplier portals. While the professional MDM vendor have viable methodologies for internal MDM processes there is an open door to the blue sky when it comes to external collaboration.

Bookmark and Share

Related Parties, Products and Locations

Henrik Gabs LiliendahlLeave a comment

Managing relationships between entities is a very important part of Master Data Management (MDM) as told in the post Another Facet of MDM: Master Relationship Management.

puzzleThere are relationships between entities within the single MDM domains and there are relationships between entities across multiple MDM domains.

Related Parties

Within customer (or rather party) MDM establishing the relationships between entities heavily increases the value of the data assets. Examples are:

  • In B2B (Business-to-Business) environments knowing about company family trees supports both analytic and operational challenges. That knowledge is often provided by enriching data from third party data providers, but as most things in life there is no silver bullet available, as the real world is quite complex and in no way fully covered by any provider I know about.
  • In B2C (Business-to-Consumer) environments knowing about how individuals are related in households is key to many analytic and operational issues too. Here having high quality location data is a necessity.

Related Products

In today’s multi-channel world there is a rush for getting product entities enriched with a myriad of attributes to support customer self-service and thus as a minimum mimicking the knowledge of the traditional sales person in a brick and mortar store.

But we also need to mimic that sales persons knowledge about how products relates. That knowledge can be collected in different ways:

  • From the manufacturer of the product. This source is often good when it comes to product relationship types as accessory and replacement (succession).
  • From the customer. We know this approach from the online sales trick prompting us with the message “People who bought A also bought B”.
  • From internal considerations. Facilitating up-sell can be done by enhancing product data with that kind of product relations.

Multi-Domain Relations

Here we may have:

Bookmark and Share

The Multi-Domain Data Quality Tool Magic Quadrant 2014 is out

Henrik Gabs Liliendahl5 Comments

Gartner, the analyst firm, has a different view of the data quality tool market than of the Master Data Management (MDM) market. The MDM market has two qudrants (customer MDM and product MDM) as reported in the post The Second part of the Multi-Domain MDM Magic Quadrant is out. There is only one quadrant for data quality tools.

Well, actually it is difficult to see a quadrant for product data quality tools. Most data quality tools revolves around the customer (or rather party) domain, with data matching and postal address verification as main features.

For the party domain it makes sense to have these capabilities deployed outside the MDM solution in some cases as examined in the post The place for Data Matching in and around MDM. And of course data quality tools are used in heaps of organizations who hasn’t a MDM solution.

For the product domain it is hard to see a separate data quality tool if you have a Product Information Management (PIM) / Product MDM solution. Well, maybe if you are an Informatica fan. Here you may end up with a same branded PIM (Heiler), Product MDM (Siperian) and data quality tool (SSA Name3) environment as a consequence of the matters discussed in the post PIM,  Product MDM and Multi-Domain MDM.

What should a data quality tool do in the product domain then? Address verification would be exotic (and ultimately belongs to the location domain). Data matching is a use case, but not usually something that eliminates main pain points with product data.

Some issues that have been touched on this blog are:

Anyway the first vendor tweets about the data quality tools quadrant 2014 is turning up, and I guess some of the vendors will share the report for free soon.

Magic Quadrant for Data Quality Tools 2014

Update 3rd December: I received 3 emails from Trillium Software today with a link to the report here.

Bookmark and Share

PIM, Product MDM and Multi-Domain MDM

Henrik Gabs Liliendahl9 Comments

Over on the Informatica Perspectives blog Monica McDonnell of Informatica seems to be determined to separate Product Information Management (PIM) and Product Master Data Management (Product MDM) as we now have the second attempt in the post PIM is not Product MDM Part 2.

I can easily see the reason for this quest for Informatica, as Informatica will very much like to position the Heiler acquisition as an Informatica Multi-Domain MDM aware PIM solution as mentioned in the post MDM Aware MDM Solutions.

There will always be pros and cons for having capabilities delivered in smaller best of breed packages opposed to in larger integrated packages. On the MDM market the vendors pitch their offerings according to how they got there. SAP is using Hybris as an eCommerce focused PIM add-on to SAP. On the other hand Stibo Systems and Riversand have been adding MDM to PIM and now adds Multi-Domain to MDM as reported in the post The second part of the Multi-Domain MDM Magic Quadrant is out.

In the PIM / Product MDM realm we have several other considerations on how to address different disciplines with technology support. An important capability within PIM is Digital Asset Management (DAM) as described in the post Digital Assets and Product MDM. DAM can be a separate application or part of PIM / Product MDM. Technology support for Data Governance could also come separately as reported in the post Data governance tools: The new snake oil?

QuadrantNow, back to PIM versus Product MDM. I’m not sure it is wise to divorce these two. It seems to be a kind of back looking exercise. I would like to marry them as part of looking forward in a multi-domain MDM world. To catch up on Monica’s arguments PIM has been much about the sell-side of things. I think we should be better at integrating the buy-side and the sell-side of Product MDM / PIM as examined in the post An Alternative Multi-Domain MDM Quadrant.

Bookmark and Share

Evergreen Data Quality and MDM

Henrik Gabs LiliendahlLeave a comment

The term evergreen is known from botany as plants staying green all year and from music as songs not just being a hit for a few months but capable of generating royalties for years and years.

Data should also stay evergreen. I am a believer in the “first time right” principle as explained in the post instant Single Customer View. However, you must also keep your data quality fresh as examined in the post Ongoing Data Maintenance.

HollyIf we look at customer, or rather party, Master Data Management (MDM) it is much about real world alignment. In party master data management you describe entities as persons and legal entities in the real world and you should have descriptions that reflect the current state (and sometimes historical states) of these entities. Some reflections will be The Relocation Event. And as even evergreen trees go away, and “My Way” hopefully will go away someday, you also must be able to perform Undertaking in MDM.

With product MDM it is much about data being fit for multiple future purposes of use as reported in the post Customer Friendly Product Master Data.

Bookmark and Share

The Calendar MDM Domain

Henrik Gabs Liliendahl6 Comments

When we talk about multi-domain Master Data Management (MDM) we usually recognize party (customer, supplier, employee) and product as the most predominant domains. The location domain is also widely understood as a separate domain. Further we can discus about assets as done in the post Where is the Asset.

Then there is the Calendar domain. In many industries calendar may just be seen as configuration data. However, in some industries calendar is a true master data domain.

CalendarOne example is in postal services as mentioned in the post The Path to Multi-Domain MDM.

Another example is public transit, an industry I have worked with in the last 16 years. Managing calendar data has many challenges in running a business or authority in public transit. Some tricky points are:

  • Keeping track of day types where different partners sees the week and public holidays differently, not at least when crossing borders.
  • Changing the day not necessarily at midnight, but at various times.
  • Assigning and monitoring services to a schedule under these circumstances.

In public transit managing calendar data has the same issues as the other more common master data domains, as calendar data may be represented differently in applications across the IT landscape stretching from back-office systems to mobile devices on-board vehicles, as examined in the post Going in the Wrong Direction.

Bookmark and Share

Digital Assets and Product MDM

Henrik Gabs Liliendahl2 Comments

Digital Asset Management (DAM) solutions are often seen working beside or within product Master Data Management (MDM) solutions.

I guess I might have been some of the first folks working with relating digital assets and enterprise software. That was in the early 90’s when I worked with Wang Laboratories that was a pioneer in handling digital images in the IT world.

Digital assets today are typically stored as files of well-known types as jpg, png and pdf. Within product MDM they are images of products, installation guides, safety handling sheets and so on.

The rise of the multi-channel theme has emphasized the importance of digital asset management capabilities.

Data quality is as ever an imperative. Related to well-known data quality dimensions that for example for product images means:

  • Uniqueness: You want to use the same image in your printed catalogue and on your web shop.
  • Accuracy: The image must show the described product and not something else.
  • Consistency: The images for similar products should have the same style.
carlsberg six pack
A random product image

Many of the leading product MDM solutions were born in the printed catalogue era. Here the product image was the dominant digital asset. Adding eCommerce and mCommerce means that a lot more digital asset types must be handled.

Usually we see digital assets as unstructured, or sometimes semi-structured, data. Therefore we often relate structured keywords in order to control the digital assets.

Digital assets should flow and should be controlled in the eco system of manufacturers, distributors, retailers and end users of the products. Here we have the same issues as with the structured product attributes. Giving the foreseeable steep increase in the volume, velocity and variety of the digital assets used as part of product MDM, we must drastically improve our capability in Sharing Product Master Data.

Bookmark and Share