Retailer 1: Data from GDSN Datapools is too bad!

If you are talking to retailers about GDSN they always complain on the data quality of the data suppliers are providing. And I was always wondering how come?

Couple months ago I was invited by a large retailer to do a data quality analysis. Reason for them was that they knew they had a problem with their product master data but they did not know what really their problems were. Everybody in that retailer complaint about the quality of their own product master data but they did not have any metrics on what was bad.

So what did we do?

First of all we went through all the departments and talked to the operational people to understand what was bad about their product master data. From their we got an extensive list of problems in their product data. The three most interesting ones were:

1. The warehouse people complaint that the measurements often were missing or wrong so that they often had to redo the intake of physical goods because the automatically calculated shelf did not fit.

2. Also the people of the tourplanning complaint about wrong and missing measurements which leads to wrong tourplanning and "overfilled" trucks.

3. The C-level people complained about wrong supplier scorecards which led to very bad discussions and negotiations with their suppliers about esp. order fulfillment.

From their we focused on investigating how good or bad measurements are in the retailers system and to see if bad master data could somehow lead to wrong scorecards.

Our results were a little bit surprising:

1. 70% of their products did not have any measurements at all in their central master data managing system or they did only have default values in there (length = 1mm, width = 1mm, heigth = 1mm, weight = 1kg).

2. We took randomly some products and compared their measurements in their different warehouse systems (as they have multiple warehouses, they have multiple instances of their warehouse system and therefore they have each item multiple times). And in most of the cases the measurements differed significantly. As they were lacking the measurements in their central system they established a measurement process in their warehouses. But obviously the people there were not able to measure the same product in the same way. Most funny was what we found for one of the private label products. The measurement for that product differed more then 100%.

3. When we tried to figure out how master data issue could impact the scorecards we found out that their system did not support a flag whether a unit is orderable or not. We could prove at some sample scorecards that this was the reason for wrong orders and bad order fulfillment. The retailer ordered a number of units which was not orderable. Because the retailer was a very good customer to the supplier, the supplier executed that order (probably after internal manual correction), and send back the dispatch advise with the correct (orderable) gtin and a corresponding amount which differed from the order. And peng: the scorecard showed a delivery error. We also had cases where the manual correction of the supplier just was wrong and he in case delivered the wrong number. But all those errors were caused because of the missing "orderable" flag and needed manual intervention on the supplier side.

4. We compared the retailers product data to the data from a datapool and found out that the data from the data pool looked completly different.

There were a lot more outcomes and results from the data quality analysis but that would really exceed that posting. I think you have now an impression how bad the data was at that retailer and what problems that caused.

Now as this retailer is doing data synchronisation already for a couple of years I was really keen to figure out why the master data can be that bad and if this is really a supplier issue.

To make a long story short we found out that the retailer from an IT perspective had implemented everything quite well. He had implemented an approval workflow where the people in the buying department could look at changes and new items coming in and then decide whether they want to take that over or to change something.

So we decided to talk to the people who were managing this approval process.

Surprise, surprise!

We learned that they preferred NOT to work with that approval process. Mainly because there were so many changes coming every day but also because they were very unsure what would happen in their backend systems when they would approve a change. Would their backend processes still work? Or would that create some kind of failure and they would be hold responsible for that failure? Therefore they preferred to not change anything because by that they could not create any process failure - they thought.

When we then looked in the queue with the items to be approved we found item changes going back until 2005!

Final surprise came when we presented our findings to the middel management. One comment I will never forget was after the whole presentation: "The product data from suppliers has to be 100% correct, as long as nobody guarantees that, we cannot work with it.".

For gods sake the c-level people got the message and launched a MDM program to start improving their master data management.

What is a MDM program?

A couple of times in my previous posts I made reference to "you have to launch a MDM program to do GDS successfully". But what do I mean with a "MDM program"?

First of all "MDM program" implies that MDM is NOT one project but it is a bunch of projects to change how you do your business or even better to introduce a new business process which takes care of your master data management. Therefore after starting your MDM initiative you will never again get rid of MDM. It will be part of your daily business.

Gartner put together a very nice framework of building blocks for a successful MDM program. The following is derived from that:

So what do the different building blocks mean?

1. MDM Vision: You should know WHAT your ultimate goal is you want to achieve in and with your Master Data Management. A possible vision might be "We want to have all our product data in one central place and synchronize it from there with our business partners. Our data quality shall be that high that we do not have any wrong orders any more due to wrong master data at our customers". That is for sure a little be short and shaky - but you get the idea, right?

2. MDM Strategy: HOW can you achieve your vision? What are the right steps? Describe how you will move forward.

3. MDM Metrics: MEASURE what you have achieved! The metrics are from my experience one of the most important building blocks and the most often forgotten block. They are so important because they link your program to your business case and by that you are linking your MDM progress to your companies success.

4. MDM Organisation & Governance: Somebody has to have the responsibility for the master data management process and somebody also has to do the actual work. So you have to define how to organize it and how to get control over the process.

5. MDM Processes: If you have an organization you also need some processes the organization should follow. Who should maintain when which master data? Who is going to approve changes? What is the flow within the organization?

6. MDM IT Infrastructure: As we are talking about electronic master data you need some IT infrastructure which will support the MDM organization and processes.

So you thought a MDM program is mainly about buying and installing SAP MDM? I think the IT infrastructure is the last part you should think about. I am convinced that if all the other building blocks are reasonably prepared and implemented for your company you could even use MS Excel as your MDM IT Infrastructure and be successful with your MDM program.

Do not get me wrong - I am not suggesting that MS Excel is the perfect MDM tool. My point is that the IT infrastructure is the least important part in a MDM program. Although my experience shows me that companies typically take it the other way round. They invest heavily in a MDM IT infrastructure and then they wonder why their master data does not improve.

My suggestion is, first define where you want to go with your master data and how to come there, and then decide what type of IT infrastructure supports you best.

Critical Myths and Realities of Master Data Management by Gartner

I really like Gartner and their view on Master Data Management.


Today they published a press release (see detailed original here) where they highlight the following 10 Myths on MDM - and from my experience, they are all absolutly correct.


In summary they are saying 

1. MDM is not about Technology
2. MDM is not a project
3. Enterprise Data Warehouses do not replace MDM
4. ERP does not replace MDM
5. MDM is not only for large and complex enterprises
6. Metadata is not the only key to MDM.
7. MDM is not an IT Effort but a Business Effort
8. MDM does not have to be a too big approach to be successfully implemented
9. Data Governance and Data Quality have to be part of every MDM initiative
10. The MDM Technology Vendor does matter, because MDM is complex and requirements for different domains and industries are different

Additional information is available in the Gartner report "The 10 Myths and Realities of Master Data Management ". The report is available on Gartner's website at http://www.gartner.com/resId=1448120.

And as my topic here is MDM and GDS I would like to add - in the original style of "myth's":

Myth 11: GDS can be implemented without MDM

Reality: MDM is the absolut prerequisite to run a GDS program successfully. Otherwise GDS will become a slow and painful project ...

Which of those myths is the reality in your company? I am looking forward your comments :-)

Even google likes my blog ;-)

I have the top listing right now :-) At least if you are searching for "mdm gds" in blogs!

That is really surprising ...

Manufacturer 2: There is no business case for GDS for suppliers!

Couple days ago, during one of those GDSN workgroup meetings, I had a chat with the GDS representative of another large, international FMCG manufacturer.

And he stated that there is no business case for GDS for a manufacturer.

He went into some details and explained that the saved costs are nothing compared to the efforts they have to spend into their IT but also into their organization to cleanse and prepare their data. And as they are currently only doing new items via GDS, he explained that it is a massive effort for them if a retailer wants to have all their current items synchronized via GDS. Reason for this is that it  means for them to prepare and cleanse couple thousand items. He estimated that it will take them one year to prepare their data!

And this company is already doing GDS for a couple of years.

Hold on a second – they cleanse and prepare their items ONLY for GDS?

I think this highlights one of the key issues with the approach of many companies to GDS. For some reason they are forced into GDS (e.g. because their customers strongly ask or even mandate GDS) and then they focus only on how to deliver data with their existing organisation, processes and IT infrastructure.

In that case it really will be very difficult to prove any business case for GDS for a large, multinational manufacturer.

I did some research also on the GS1 GDSN website http://www.gs1.org/gdsn. This is normally a very helpful ressource and you can really find some hints regarding business cases. E.g. you can find something here http://www.gs1.org/docs/gdsn/gdsn_brochure.pdf.

But esp. this brochure starts with an assumption which is not payed enough attention to. The very first sentence of this brochure reads “Every company in the world has a database filled with
information about the products they make, or sell, or buy.”.

And this is just not the case, because most of the companies in the world do NOT have “a database filled with correct and complete information they make, or sell, or buy”.

This is all MDM is about!
The ultimative goal of the MDM discipline is to setup an organisation, processes and an IT infrastructure to create and maintain “a database filled with correct and complete information about the products they make, or sell, or buy”.

Coming back to the business case.

I think it is already very obvious that you have to look at least at two business cases. One for the MDM program and a second one for GDS. The MDM program thereby is  a prerequisite for the GDS implementation. But the MDM program does not only help the GDS initiative, it also smoothes a lot of other business processes and that is where you get your earnings from your MDM program.

For example if your product measurements get improved, your logistics processes (warehousing, tour planning, …) will be improved.

But this is a whole new story and I will post some of my thoughts and experiences regarding business cases for MDM programs in the next couple of weeks. But maybe I should first describe what I think is a MDM program? Ok, that will be my next posting :-)

Summary for the GDS business case for large manufacturers: Do not mix up the efforts you have to spend to build your “database with correct and complete product information” with the efforts you have to spend to synchronize this database with your business partner! Those have to be two different business cases. And both can be calculated very well. I have done it already :-)

Manufacturer 1: Doing GDS for years now - but MDM?

Couple days ago I talked to a big, multinational active FMCG manufacturer who is already doing GDS for years now.

I thought that they should have a very solid MDM program in place and that they should by now master the whole GDS stuff very easily. When I was talking to them my thoughts got even underlined, as they perceived themselves as quite progressed in their GDS approach. They esp. highlighted the complexity of their products because they needed to deal with display shippers, promotional information and also with dangerous goods information!?

For some reason we asked them to provide some test data to us. When we jointly looked at it they admitted that they have not yet implemented neither the promotional stuff, nor the dangerous goods stuff!

I was really surprised - to not say shocked!

They are doing GDS for years, but they have not been able to implement key attributes for their core business!? You would think that this is only adding some simple mappings and maybe your MDM Team to collect the data from the right systems or - worst case - from the right people (if you are an alerted reader you immediately would stop here and say: "Hey, that implies that you have an MDM Team in your organization and that your IT Infrastructure allows for simple mappings. That is not always a given!").

I am not in the details of this company, therefore I cannot really judge what the real reasons are for that situation. And they also did not tell me.

But if I would be asked to give my best guess - I am quite convinced that they failed in setting up a proper MDM program. In one of my next posts I will describe in some more detail what I see as a "proper MDM program", so stay tuned ;-)

In this case I think it failed straight from the beginning. I think they did not have an appropriate vision where they want to go and therefore they also went wrong in their strategy, how to reach that vision. Either it was to complex, or they did not take GDS in account, or their only vision was "let's implement a PIM".

Can I be completely wrong? Maybe ... but why are big, multinational manufacturers struggeling so much, to do GDS? With the right MDM program (esp. organization, processes and IT infrastructure) it should be manageable.

I am overwhelmed :-)

That is really great, first blog posting and within 3 days 59 people from 10 countries have read it. And it is not only my friends (like Thilo, lawyer from NY - @Thilo: I would not mind if you stop following if it is getting too boring for you ;-) but also real people from the GDS and MDM community. Met today a guy from Italy and one from Spain and both mentioned that they have read it :-)

Congrats to all of you! And keep following - and commenting ;-)

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.