Sunday, January 16, 2011

What are the key issues with GDS in an MDM implementation?

This blog post was triggered by a question which was posted on linkedin: “What are the key issues associated with data synchronisation and data governance in an MDM implementation. Further on, what are the common techniques to resolve those issues ?”.

My first thought was “Hey, that is easy. Just hold on for a second” … now it already took me two days to come up with some key issues. Feel free to comment on those :-)

First of all to do GDS successfully you have to implement a MDM program otherwise your GDS program will be one of your most painful and costly exercises you ever did.

Ok, now let’s assume you have decided to setup and start a MDM program and GDS will be one of the consuming channels for your item master data. What kind of issues will you face and how can those maybe tackled?

1. Data modeling – Global Standard vs. Local / Company Standard

One of the basic requirements if you want to do synchronization of item data between companies is that you agree on syntax and semantics of the data you are exchanging. Therefore GDS defines all the attributes, attribute types, code lists, classification systems and validation rules the data has to comply to.

As nobody starts on the green field, typically you have already a huge chunk of the data you want synchronize or at least you have already the data model because it is already in your existing IT systems.

At the first glance it sounds like a simple mapping task to simply map the global standard to your local standard or vice versa.

But the challenges are in the details. For example think about your category system and the Global Product Classification (GPC). The use of the GPC is mandatory in GDS. The typical situation is that in some categories your category system is more detailed, while in others GPC is more detailed. And off you go – a simple mapping is NOT possible!

For sure you can think of many workarounds, starting with more intelligent mapping algorithms which try to map on item level using more item information and ending with manual classification of each item.

But the best solution is to figure out whether GPC fulfills your business requirements and to replace your proprietary category system with the Standard.

Same goes with attributes and their types and also with code lists.

2. Really support the GDS item confirmation process (CIC)

GDS does not only provide the possibility to publish item data, but also for the data recipient to send back a confirmation information which allows to request changes in the data or simply to confirm that the data has been accepted and put into production.

As a supplier you have to be aware that your customers might give you feedback on your published data via this channel. This means you need the IT infrastructure to support this but also to have a organization and processes in place to deal with that feedback from your customers.

As a retailer or general data recipient you should be aware that your suppliers expect you to receive comments on their data via the GDS channel and not via a phone call. So also you as a retailer need the IT infrastructure and the processes and organization to support this.

And this has to be part of your MDM program!

3. GDS Impact on your MDM Organisation and Processes

With GDS your data leaves your scope of control and this puts additional requirements on your organization and your processes.

If you are a supplier or manufacturer and you want to publish your item data to your customers your organization needs a role that is talking to your customers and figures out what their data requirements exactly are.

Why do you need to know about their detailed requirements?
Because although you will be using the global standard, there are a lot optional aspects which might be considered mandatory for some of your customers and optional for others. Some will also have different (meaning stricter) validations. Some might require some non standard data on top. And in many cases how the electronic GDS process links to the “manual” listing process will differ from customer to customer.

Why do you need a “customer-coordination” role?
This role will be the single point of contact for your customers and your sales department whenever there are issues regarding data synchronization. With that role you have clear responsibilities.

If you are a retailer you also want to establish a similar role, which is the central contact on the one hand side for your suppliers and on the other side for your purchasing or category management department.

Those were the first ideas which came to my mind when thinking through the key issues GDS brings to an MDM program.

I would be happy if you would comment or add whatever your experience in this area is.


  1. Would like to add bellow points
    1.Ability to Relate GDS data model to End customer data model.
    2.Internalization standards: Having single MDM system across the Globe.
    3.Ability to support full range of products. for example Product range in Amazon,ebay,etc..

  2. Yes, agreed. I think those are really important topics to take into consideration.

    Regarding relating the GDS data model to the customers data model I also mentioned that already in my original posting. Maybe I stressed to much the GPC as an example. Actually this already might be two different topics.

    Having a single MDM system across the Globe I also regard as the ultimate goal. Although I think this becomes more and more a challenge the bigger and more globalized the company is we are talking about. Nevertheless standardization internally is the ultimate goal.

    And finally I am also convinced that the MDM should be the one and only true source for your master data. Although there are also different deployment and implementation proposals to actually achieve that.