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

Why is Customer NOT a Master Data Entity?

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.

Party Transactional Roles Logical Data Model
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!

By starting with this data structure enterprises will no longer have to trudge through a quadrillion records trying to establish a ‘Single Customer View’.  They will actually start off with, and maintain, a single view (not of Customer) but of Party.  Simple, yet amazingly powerful!

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

2 Responses to “Why is Customer NOT a Master Data Entity?”

  1. Lyman Zurger February 17, 2014 3:32 pm #

    Gorm, I like your flexibility.

    Thanks for the strong post John. Respectfully, I’m on the other side of the argument, at least when starting out on an engagement with conceptual modelling.

    When working a conceptual model at the enterprise level or for a business domain, a Party entity hides information and parks the `Who` questions until logical design, or later. It drives distinctions between party roles out of information structure and into lists of data content. It encourages the resulting data quality problems right from square one. Often I haven`t been able to impose discipline on the shop to manage role values. The strong data governance required to manage content is usually perceived to be too expensive, especially across redundant data stores. The best tool I have is a conceptual model that illustrates roles explicitly.

    A Party entity is a necessary evil when designing a physical database (or buying one) because anything more role-specific is usually too inflexible over time. It’s easier, but I don’t like it all that much.

    That`s my $0.02! Cheers, John.
    Zurg

  2. Gorm Braarvig August 29, 2012 9:25 pm #

    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

Leave a Reply