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

Customer is Not a Master Data Enitity.

Having Customer and Supplier as Master Data Entities is about as sensible as having Creditor and Debtor.

Why? Because all of these terms refer to derivable relationships and implementing them as Master Data Entities is both a modelling and business error. If this is true, why are they so often modelled as such?

It all starts with analysts misunderstanding business terminology. Bad analysts hear the terms ‘Customer’ and ‘Supplier’ being used throughout the business and imagine that these elements are definitely Master Data Entities – “they must be, that are not transactional entities” – and model and implement them as such.  Some of these analysts are publicly passionate about this approach, saying that it shows that the ‘listen to the business’.  I wonder what such analysts implement when they hear the term ‘Punter’ being widely used in some businesses?

Good analysts also listen to the business. However, instead of blindly implementing structures based on the terminology in common use, they look for the truth behind the terms and hear what is really being said.

One of the most empowering questions an analyst can ask is, “what do you mean by…?” So, when good analysts hear a member of the business talk about ‘Customer’, instead of falling into the trap of thinking that this is so obvious that it would be silly to ask, “what do you mean by ‘Customer’?”, they ask the question and begin a dialogue that will bring a new insight and power to the business.

So let’s begin the dilogue.

Analyst: “What do you mean by ‘Customer’?”

Business: “It’s anyone to whom we sell our products and services.”

Analyst: “Are these customers individuals or organisations?”

Business: “They could be either.”

Analyst: “Could you sell things to people or organisations who supply you with products and services?”

Business: “Yes, we could and we do.”

Analyst: “Could you sell things to your employees?”

Business: “Yes, we do all of the time”

Analyst: “Could you buy products or services from your employees, other than the services covered by their employment contract?”

Business: “Yes. A lot of the artwork that we sell we buy from our employees.  Some of them are quite famous locally.”

The above dialogue shows that the term ‘Customer’ refers to a relationship that the business has with a third party, either an individual or an organisation.

The dialogue also shows that the business can have several relationships with a single third party, for example, ‘Customer’, ‘Supplier’ and ‘Employee’.  All of which have traditionally been seen and modelled as ‘master’ entities.

Because ‘Customer’ is not in reality an entity, but a derivable relationship, it ought never be modelled as Master Data.

The  simplifies several definitions:

A ‘Customer’ is any third party to whom the business has sold products or services.

A ‘Supplier’ is any third party from whom the business has purchased products or services.

An ‘Employee’ is any third party with which the business has set up a contract of employment.

We could add to this:

A ‘Creditor’ is any third party that owes money to the business.

A ‘Debtor’ is any third party to which the business owes money.

A good analyst will definitely be hearing the repetition of the phrase  ‘Third Party’ in the above definitions, which suggests that this might very well be the key element around which to build the Master Data Model. What do you think?

If you liked this post and think that it could be of value to a colleague or friend please share it by clicking on one of the social media links below.


One Response to “Customer is Not a Master Data Enitity.”

  1. Richard Ordowich November 23, 2011 1:14 pm #

    Before determining what data is “master data” we have to ask the question why do we need master data? We’ve heard; “single version of the truth”, “golden copy” and other unachievable goals that give the impression that master data will solve all the ills of data quality, legacy systems and siloed business processes. Some suggest that reference data should be considered master data.

    Then things get even more abstract with claims that in order to manage master data you have to have data governance, as if the data is rebelling and requires a dictatorship.

    But what they fail to explain is specifically how master data will help the business. How will all the users, business processes, applications, databases etc. use the master data and how will it improve?

    Conceptually defining data sets as “master” sounds feasible. But once you begin to examine all the various contexts, meanings and interpretations of master data such as customer, you realize data has many “masters”.

Leave a Reply