Many enterprises see Customer as their most important Master Data Entity and, as a result of this error – and it is an error, they sabotage all efforts to effectively manage ‘Customer’.
The fact is that Customer, Supplier, even Employee are NOT Master Data Entities!
How can this be? How can entities that play such important roles in the enterprise not be Master Data Entities? Because that is what Customer, Supplier and Employee are – merely Roles!
They are Roles played by parties with whom the enterprise does, or wishes to do, business. The clue to the real Master Data Entity lies in that last sentence, the word “Parties”.
The actual Master Data Entity that enterprises ought to be managing is Party. The enterprise does business with Parties. It buys from them, sells to them and employs them.
A single Party can, over time, play many Roles through its Transactions with an enterprise. The diagram below shows the Logical Data structure that models all of the Roles that a Party might play over time.
The power of the above structure is that, although there might be thousands, even millions, of times that a Party plays the Role of ‘Customer’, ‘Supplier’ or ‘Employee’ over time, there will only be the one occurrence of that Party!
Multi-Dimensional MDM
I have now developed a completely innovative approach that combines these powerful modelling techniques with a completely new way of thinking about MDM, that I call Multi-Dimensional MDM or MDMDM. This approach will enable you to take your Master Data Management thinking and practices to an entirely new level.
I introduce MDMDM, plus all of my latest insights on Master Data Management, in a series of FREE MDM Webinars that I am currently running. Click here to Enroll on MDM Webinar now.
I have also taken all of my insights and modelling techniques and built them into an exciting new Online Multi-Dimensional MDM Course. This course starts at the end of August but is available for enrollment now.
If you enroll prior to 31 August 2012 you can get a 30% discount by entering this code at checkout 4MDM1207
If you know of any friends or colleagues who would benefit from finding out all about these innovative MDM techniques and insights then please share this link with them: http://eWebinars.com/5444/4fpnuj3ted/webinar-register.php?trackingID1=Blogpost&trackingID2=MDMWebinarAd&landingpage=default&expiration=default
Multi-Dimensional MEM (MDM) Online Course 
Online Mentoring 
Information Flow Modelling eBook 
Business Process Modelling eBook 
Data Structure Modelling eBook 
I have some comments.
I work from the belief that the level of abstraction depends on the goal.
- “Object” might be too abstract?
- “Actor” might be the correct level of abstraction
- “Party” might be the best
- “Customer” can be good
- “Client” might be better
- “Car buyer” can be too little abstract?
some percieved pros of high abstraction:
dynamical and looks professional and intelligent, can be communicated as strategic (large horizon)
some percieved cons of high abstraction:
complex, inprecise and in need of context (“role” in your sample), cost and risks are high, can be communicated as operational (strong focus)
I find Context/Role particularly expensive in terms of ownership and integration.
but absolutes here just doesn’t make sense to me
Example: we want to convert our business from doing blablabla and convert to yadiyadi: high abstraction is good if we do not want to communicate our intent (“Object”/”Actor”), if we want to communicate our intent we drive through our purpose (“Client”/”Car buyer”).
Best Regards,
Gorm Braarvig
Practice Manager, MDM&EA