Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

MDM Seven Fatal Errors & How to Avoid Them!

The business practice referred to as Master Data Management (MDM) is plagued with Seven Fatal Errors that prevent enterprises from achieving any real success in this area, no matter how much effort or money is thrown at the problem.

What are these Fatal Errors?

  1. Calling it MDM!
  2. Looking in existing data for Master Entities.
  3. Using misnomers like Customer, Supplier, etc for the Master Entity of Party.
  4. The Curse of the Systems SILO.
  5. Mistaking Unique Codes for Unique Identifiers.
  6. Mistaking Address for an attribute of Party
  7. Not using the Logical Data Model

In this article I will address each of these Fatal Errors in turn and, more importantly, describe how they can be easily avoided.

Error 1: Calling it MDM

This first Fatal Error in this area is calling it ‘Master Data Management’! Calling this core set of activities by the wrong name starts it off in the wrong place and heads it in the wrong direction. The fact is that there is no such thing as ‘master data’!

What is actually being managed are the Master Entities of the enterprise and, for that reason, this set of activities should be termed Master Entity Management (MEM). True, we do hold data about these, but it is the management of the entities, not of the data, that is key to success. The quality of the data of the entities will need to be managed, but that is a subsidiary part of managing the Master Entities themselves.

This misnaming is historical and came about because this whole area has been mismanaged for some time now and is probably worse off that it was 20 years ago.

Many of the core skills and techniques that are essential for Master Entity Management have been forgotten. Indeed, many practitioners have never even learned them. For that reason, most enterprises start in the wrong place by trying to sort out databases full of error-laden data relating to Master Entities and believe, erroneously, that this will sort the problem.

Solution?

The solution starts by calling this core set of activities by the correct term, Master Entity Management. Will this solve all of the problems? No. But it is the foundation for a solution.

Using the wrong name makes a solution impossible to achieve as all efforts are pointed in the wrong direction. By using the correct name it becomes possible to identify the true faults and, more importantly, ways of rectifying them.

Error 2: Looking in the Wrong Place

Having started off by calling Master Entity Management by entirely the wrong name, MEM When it come to MDM, existing data can be a junkyard.practitioners further compound their error by looking in entirely the wrong place for the Master Entities of the enterprise.

And where is this? In the existing data! Why should they not look there?

Unless Master Entity Management is already well established in your enterprise, then your existing data on your Master Entities is probably as far from what it ought to be as it is possible to get. So, looking there for your Master Entities makes about as much sense as looking in a scrap yard for the components for a Formula 1 racing car.

Solution?

The only way to find out what the Master Entities of the enterprise are is to ask the Senior Executive team the six Multi Dimensional MEM questions.

The six questions, which will lead you to the Master Entities for any enterprise, are:

  1. What Types of things do we make, buy, sell, improve or trade?
  2. Who do we Buy From and Sell To?
  3. Who Benefits from our Products and Services?
  4. Where are our Customers, Suppliers, Beneficiaries, etc. located?
  5. What Resources do we use to Make, Buy, Sell, Improve or Trade our Products and Services?

Error 3: Muddled Misnomers

Using misnomers like Customer, Supplier, etc. for the core Master Entity of the Enterprise is our next MEM/MDM Fatal Error.

Customer is NOT a Master Entity! This will come as a shock to all of those enterprises that see Customer as their most important Master Entity and spend so much time, energy and money trying to achieve things like a ‘Single Customer View’.

The truth is that they have got it wrong and their approach is a major cause of fragmentation of the Master Entities in enterprises around the world.

If Customer is not a Master Entity, who does the enterprise do business with?

They do business with legal entities or parties other than the enterprise itself. For this reason, a more appropriate name for this crucial Master Entity is ‘Party’.

If Party is the correct name for the Master Entity, what is ‘Customer’? It is a Role played by a Party in a commercial transaction with the enterprise.

Solution?

Be aware that one Party can play many roles, such as Customer, Supplier, Guarantor, Beneficiary, even Employee! Although all of these Roles are crucial to the survival of the enterprise, they are NOT Master Entities and mistaking them to be such, will cost the enterprise dearly.

Error 4: The Curse of the Systems Silos

One of the major causes of fragmentation in MEM is the ‘Silo Mentality’ that pervades nearly every enterprise due to the widespread use of third party applications or packages – also called Commercial Off-the-Shelf (COTS) software.

A typical package of this type would be a Customer Relationship Management (CRM) application.

In the silo world of the CRM application there is only one Role for Party and that is Customer, so it is called ‘Customer’.

Everybody who works with these packages gets sucked into the Silo and they too start to believe that Party is really Customer.

Likewise in the silo world of the of the Supplier Management, where Party is mistakenly called Supplier and where all concerned believe it to be so.

The same error is repeated around the enterprise in the worlds of HR, Marketing, etc.

The Curse of the Systems' Silo

Everywhere that you have a Silo application you will have a “silo mentality”, bringing fragmentation and duplication.

Solution?

What is required is central management of the Master Entity of Party.

This requires unified and integrated thinking and a centralised system that holds a single view of Party that can be used by all other satellite systems.

The starting point for such integrated thinking is a Logical Data Model that shows the Master Entity of Party in its true light and Customer, Supplier, Employee, etc. for what they really are – Roles. Important Roles. Vital Roles. Yet just Roles – all played by the core Master Entity of Party.

Party Transactional Roles Logical Data Model

Error 5: Mistaking Unique Codes for Unique Identifiers (UIDs)

This error is perhaps the single greatest cause of duplication of Master Entities in systems around the globe. The most common example of this is the belief that Customer Number is the unique identifier of a Customer.

What is wrong with doing that? Several things.

As we saw in Fatal Error 4, there is no such Master Entity as Customer. The actual entity is Party.

Having this ‘unique code’ mentality results in one part of the enterprise giving Party the unique identifier of Customer Number, another part giving it Supplier Number, and in yet another part giving it Employee Number and so on.

So here we have (at least) three different unique codes posing as the unique identifier of the same entity in the same enterprise.

So, what is the solution? A Party Number? Well, Party Number would definitely be a useful mechanism for removing the proliferation of other numbers around the enterprise, however, it would not be the unique identifier of Party.

The fact is that unique codes are never unique identifiers!!!

Imagine we had three Parties with unique Party Numbers as follows:

P00123 John Owens
P00124 John Owens
P00125 John Owens

.

Are these three different Parties? Well, according to the Party Codes they are. However, the Party Name suggests quite the opposite. It does not prove it, but is strongly suggests it.

Solution?

How would we find out? We would actually look for more information on Party, such as age, gender, address, etc.

From this we can see that the information that we need to uniquely identify a Party has nothing to do with the Party Number, it has all to do with other key data about Party.

The question we must ask to guide us to the defining the unique identifier of Party is, “With regard to this enterprise, what is it that makes one occurrence of Party uniquely different from every other occurrence of Party?”

This will never be a code! The fact is that codes do not identify entities, they are merely a mechanism for referring to them. Because they do not identify them, they can never uniquely identify anything.

Unique identifiers for Party are a challenging subject and are covered in much greater detail in Module 2 of the Multi-Dimensional MEM Online Training Course.

Error 6: Modelling Address as an Attribute of Party

One of the major misunderstandings that pervade Master Entity Management is that of modelling address as an attribute of party.Party entity with address attributes ibcluded in error.

How many times have you seen a data entity or database table with the structure shown on the right?

But why is this structure wrong? Ask yourself, ‘What happens if the Party changes address?’ Do the values for house number, etc. all get overwritten?

If so, how do you know where the party lived before the address currently displayed? How long did they live there? How often did they move?

Also ask, ‘Who else lives at this address?’

This structure will not allow you to answer any of these questions.

It is only the attributes above the line that actually belong to Party. Those below the line belong to another entity entirely. The proper name for this entity is Location.

Solution?

Move all address details out of Party into an entity called Location. Because a Party can be legitimately associated with many Locations over time, the relationship between Party and Locations is a many-to-many. This means that it needs to be resolved by an intersection entity called Party Location Usage. This is a very powerful entity that shows what use a Party makes of Locations, for how long and what other Parties also make use of these Locations.

MDM Data structure for Party LOcation Useage

Error 7: Not using the Logical Data Model

This is a case of the last being first and the first being last.

The fact is that if enterprises were to model the structures of their Master Entities in the form of Logical Data Models (LDMs), then all of the preceding six errors could be avoided!

Amazing as it may seem, there are comparatively few MEM/MDM practitioners, who use, or can use, Logical Data Models in the course of their work. This fundamental skill has been lost over the last few years and has given the world very many, far too many, MDM practitioners without the necessary skills to successfully implement Master Entity Management in any enterprise.

Because they have lost the core skill they try to push forward a whole raft of technology based solutions, such as Big Data, Real World Alignment, MDM in the Cloud, etc.

All of these technologies have a lot to bring to MDM, however, unless the fundamental structures of the Master Entities of the enterprise have been robustly modelled at the logical, they will bring absolutely no benefit – quite the reverse.

The use of these technologies actually presents a significant risk to any enterprise that has not carried out proper logical modelling.

Solution?

There are five essential actions to take in order to assure the quality of, not just your Master Entities, but of all of your data. These are:

  1. Bring Logical Data Modelling to the heart of all Master Entity Management and Data Quality and activities.
  2. Train a core group of people (this would include analysts and business managers) in the fundamental skills of Logical Data Modelling and locate this team in the business, NOT in IT.
  3. Build a Corporate Business Functional Model for the enterprise, as this defines all of the data that is required by the enterprise.
  4. Build a Corporate Logical Data Model showing the elements and structures of the data required by the Business Functions.
  5. Use these two models as the foundation on which you make all of your decisions on systems development and procurement for all parts of the enterprise.

MEM/MDM Resources

Here are some further MDM resources that you might find of use in your work:

View a free Webinar on Multi-Dimensional MEM

Preview the modules from an online course on Multi-Dimensional Master Data Management (MDM).

Subscribe to my MDM newsletter and get all of my latest Hints and Tips.

Work With Me

If you would to work with me and prevent these MDM Fatal Errors occurring in your enterprise then  email me at john@jo-international.com or Skype me on johnowensnz. I look forward to connecting with you.

Tags:

2 Responses to “MDM Seven Fatal Errors & How to Avoid Them!”

  1. Jean Francois Pirus May 30, 2013 3:17 pm #

    Thank you John with this very clear picture.
    I am glad to find some experienced guy sharing our view on this subject.

    I would add a last (but not least) fatal error : to restraint this subject to technology or data modelling whereas you have to be clear about your “MDM” processes : who is entitled to update / or ask for updating a reference data?
    In real life, you may have one reference database but many authorised sources who are eligible for creating / updating data such as customers address for instance. What are the business rules ? Is there any need for reverse update,…

  2. Peter Perera May 22, 2013 5:03 pm #

    John, I second all your thinking. In my own experience you are completely spot on. For years, much of my work with clients starts out first getting them to also think along these lines so we can then productively and meaningfully move forward. Seems I’m always having to undo the deeply entrenched misconceptions you so clearly and simply highlight. Glad to see I’m not alone in also having picked up on the same MDM errors.

Leave a Reply