Thursday, April 14, 2011

What is “100% Data Quality”?

Isn’t your goal “100% Data Quality”? And don’t you expect (at least if you are  a retailer) your suppliers to deliver via GDSN 100% correct item data?

But what does this simple term “100% Data Quality” really mean?

Imagine that you are a retailer. You are receiving item data from your suppliers via GDSN. You are feeding that data directly and exclusively into your warehouse system. And your warehouse is fully automated so you are really dependent to receive from your suppliers the correct measurements. So you are very proud of your warehouse logistics and you are managing that in the most efficient manner which gives you serious benefits over your competition. But because you are so focused on efficient logistics you have not yet implemented any ecommerce strategies and therefore you have very little demand in any additional product information like nutritional information or things like that.

So for you “100% Data Quality” does mean – get me the measurements and my other logistics information (like packaging hierarchies) correct!

Now imagine you are a e-commerce retailer. What you need to sell is good images and very detailed product feature descriptions. If you are selling food you need nutritional and allergen information. In some countries you need this already for legal reasons.

Now “100% Data Quality” means logistic information including measurements + feature information + images.

And now try to imagine what “100% Data Quality” means to a small supplier who is confronted with forms with hundreds of attributes to fill out. He is happy when he gets his data passed the damn data pool validations!

Got my point?

Data quality – and my examples so far only touched on the completeness of the data – is “relative”. It is dependent on the requirements of the recipient. If you are using the measurements in your systems and your business processes depend on that information, you need it to have “100% Data Quality”. If you do not use it you can still have 100% Data Quality for your purposes if the measurements are incorrect or even empty.

Same applies for all dimensions of data quality: correctness, completeness, in time delivery and validity.

Imagine the perfect world all retailer requirements regarding data quality are equal because they are fully using the full set of product information in all their processes. But in todays world implementation levels of retailers are different and therefore they today might have very different requirements depending on the business processes where they are using the data today.

My recommendation to retailers would be, give a clear communication and documentation to your suppliers what you consider to be “100% Data Quality” and build into your system validations to ensure that quality level including feedback for suppliers if their data does not meet those requirements.

To suppliers I recommend ask your retail customers what they understand under the term “100% Data Quality”. Then start implementation accordingly.

Tuesday, April 5, 2011

MDM and GDSN hard to connect? The original post ...

Actually when I started writing my last blog post on the topic why MDM and GDSN are hard to connect my original intention was not to write about a flaw in the design of GDSN. This just happend to come to my awareness while I was thinking through the whole "How to connect a MDM system to GDSN?".

My original thought was that GDSN actually allows - and in my view even "requires" if you want to get all the benefits out of it - interaction between the supplier (data source) and the retailer (data recipient) when you are synchronising item data. This interaction is mainly the feedback from the retailer to the supplier what he has done with the data on item level via the CIC (Catalog Item Confirmation) message.  With the CIC message the retailer can ask the supplier to review the send data because it might not comply with the retailers data requirements or he simply can indicate that he has accepted the data and synchronized it with his backend systems.

This type of interaction between data source and data recipient is very unique to GDSN. I am not aware of any other item data exchange standard which has a similar technique.

In a MDM system the typical approach for data integration is on the data source side more a "fire and forget" approach. That means you are maintaining your master data in the MDM system until it is approved and then you are publishing it for the consuming systems. Typically a MDM system does not expect any feedback on its publication. If you are lucky you are using some kind of EAI tools for the data distribution and that is handling at least technical protocols regarding the success of the data distribution. Those protocols are then typically managed by some technical teams.

But the GDSN CIC process is a business process! So the CIC feedback has to be dealt with on the supplier side by the business people who are normally maintaining the item data. So your MDM has to provide some kind of user interface for its users to see CIC's which have been received and to process them efficiently.

On the data recipient side it is a little bit different. There your MDM system has validation rules to ensure the data quality of your item data. If the data you are receiving from a supplier does not comply with those rules your MDM system has to be capable to send back a CIC review message automatically. On top of that your MDM system also has to enable its business users to either accept or send back a review manually because not everything can be validated automatically.

And as those workflows are very unique to GDSN there is no generic solution for it in MDM systems. If you look at MDM systems which have implemented a standard connector to GDSN they all have implemented a separate module (a "GDSN console" or something alike) to deal with those special processes.

It is even getting worse if you also take price synchronisation into account. In GDSN price sync is a different message set and a different choreography from item sync. It is in a way similar (similar message names, similar idea of the choreography) but the details are then quite different. For example is the "Price Sync Confirmation" process not optional like in the item sync process but it is mandatory. Additionally you also first have to synchronise and accept a business relationship before you can start synchronising prices.

Right now I am not aware of any MDM system that has implemented support for the GDSN Price Synchronisation!

And that is doubting the whole value of a GDSN implementation in my view. If I am only able to synchronise item data and no price data my business problem is only solved half. I then still have to find a solution how I can synchronise prices between trading partners. And they really want to get rid of those error prone, not versioned, not processable Excel sheets!

So if you want to connect your MDM to the GDSN (either because you are the software manufacturer of the MDM or because you have introduced a MDM system into your business) be aware of the business processes GDSN implies. They have to be supported.

Also be aware that only the whole GDSN package of Item sync + Price sync really unlocks the whole value of GDSN for you.

Just to be fair I should mention here that price sync adoption today is really low globally - to not say zero if we except Australia. But Australia is a good proof that it can be done and really brings the value expected!