Process of consolidating Master Data


In my previous blog post “Multi-Purpose Data Quality” we examined a business challenge where we have multiple purposes with party master data.

The comments suggested some form of consolidation should be done with the data.

How do we do that?

I have made a PowerPoint show “Example process of consolidating master data” with a suggested way of doing that.

The process uses the party master data types explained here.

The next questions in solving our business challenge will include:

  • Is it necessary to have master data in optimal shape real time – or is it OK to make periodic consolidation?
  • How do we design processes for maintaining the master data when:
    • New members and customers are inserted?
    • We update existing members and customers?
    • External reference data changes?   
  • What changes must be made with the existing applications handling the member database and the eShop?

Also the question of what style of Master Data Hub is suitable is indeed very common in these kinds of implementations.

Bookmark and Share

4 thoughts on “Process of consolidating Master Data

  1. Jim Harris 27th September 2009 / 18:15


    These types of discussions are always better with the detailed context and case study that you have provided via the excellent supporting PowerPoint slides!

    Great job showing the consolidation steps, including parsing the input data, using external reference data during standardization, and data matching for de-duplication.

    Thanks and Best Regards…


  2. william el kaim 29th September 2009 / 07:31

    Great Post. In France, some people worked together to provide best practices to the community (also in english).
    All comments and help appreciated.

  3. Phil Allen 29th September 2009 / 14:07

    If I have understood your presentation correctly then the resultant master data has 5 entries:-
    1 Household containing 2 Consumers
    1 Business containing 1 Employee.
    However, there is a match between Margaret the Consumer and Margaret the Employee which could be consolidated into a PartyType of ‘Person’. I.e. the data now may benefit from a normalisation exercise to arrive at a single source of stored data.


  4. Henrik Liliendahl Sørensen 29th September 2009 / 15:30

    Thanks Jim, William and Phil.

    @Phil. Exactly. I did assign the same ConsumerID to the 2 Margaret rows, but PersonID might be better naming.

    The next step in a conceptual modeling could certainly be to have model like the one referenced by William having a person entity (like in the real world). The processed data could nicely fill into such a model.

    (However I sometimes encounter the next challenge is not the excitement of building a brand new data model but rather the hard work of squeezing the data into an existing model say from a ready made CRM product.)

Leave a Reply to william el kaim Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s