A basic structure of B2B (Business-to-Business) Party Master Data is that you have accounts being business entities each having one or several contacts being employees in each business entity. These employees act in the roles of decision makers, gate keepers, invoice receivers and so on. In Data Model language there is a parent-child relationship between accounts and contacts.
When doing deduplication with such data you aim to make a golden copy with unique business entities having unique contacts.
After achieving that you may gaze the data and stumble over rows in the golden copy as these (function, contact name, account name, address):
- HR, John Smith, Smashing Estates Ltd, Same Place in Anytown
- HR, John Smith, Smashing Solicitors Ltd, Same Place in Anytown
- …
- IT, Tushnelda von Keine-Mustermann, The Old Treadmill Ltd, Anytown
- IT, Tushnelda von Keine-Mustermann, Brand New Brands Ltd, Anytown
Duplicates? Probably it’s the same real world individuals.
John Smith is the ultimate Anglo common name, but if your favorite external business directory tells you that the 2 companies has the same mother and are modest size organizations, the possibility of John Smith being the same person having the same role at the same time in 2 companies is very high.
Tushnelda has a very unique name, so here there is a high possibility that she has got a new job in a new company, which makes one of the entries inactive. If one is going to be selected as the active survivor it may be chosen from newest update, found in external reference data or investigated otherwise.
B2B is often not actually Business-to-Business but also E2E – Employee-to-Employee – as the relationship exists between employees in the selling and buying business entities and it is not unusual that the relation may follow the employees when they change employer.
So striving for “one version of the truth” through “360 degree view on customer” is not a one layer exercise. This fact must be modeled in the Master Data structure, supported by functionality and prevented by feasible data quality implementations.
It’s my plan to do some blog posts around hierarchies in Party Master Data and how this must be handled in data matching. Next post will be about B2C data.
Liliendahl on Data Quality 
Good, clear, real world examples – I like it. Ken.
When such occurrences of data appear in a table then the question must be asked: “What is the difference between the two rows?” and, if there is a difference, “What is the significance of that difference?”
In the context of the examples given, these differences would tend to be the “role” that the person is playing. The creation of an entity called “Role” will enable all ambiguity to be resolved.
Asking the question “what is the nature of the relationship with the person in question” will also usually result in the answer “it is role that the person is playing”, thus making the creation of the entity Role obvious.
Once the entity Role has been created, it must then be established whether or not the First Name and Surname of the person playing the role are merely attributes of Role or whether Person needs to be an entity in its own right.
I have created an entity relationship model displaying several viable options that can be viewed at http://www.integrated-modeling-method.com/data-modeling/customer-contact-structure
Thanks a lot John. I made a comment on your post.