Let’s proof “What are the Positives and Negatives of GDSN?”

Björn wrote this Blog article http://themdmblog.blogspot.de/2012/04/what-are-positives-and-negatives-of.html about one year ago.

As we have a global supplier as customer for a GDSN project I’ll pick up this topic and keep you posted. We’re currently in requirements analysis phase. Let’s start with a look at some of the mentioned “Positives” from this view point:

“1) GDSN is the only global infrastructure to exchange product information.” and “2) It is used by many global suppliers and retailers.”

The customer is a global company. It is already using GDSN (in its 1SYNC implementation) to ex­change product information in the US. Now Europe should follow, extending and leveraging the data pool connector implemented by the company’s global IT. So, the choice for GDSN to exchange product information makes sense.

“3) It has a lot flexibility build in with the extension concept and extensions like the AVP-Extension.”

The customer wants to transport quite a lot of textual information on its products. Plus some specific attributes which did not find their way into the extensive GDSN data model yet. Therefore the generic attribute name/value mechanism given by the AVP Extension provides the needed flexibility. However, I need to come back to this point looking at “Negatives”.

“4) There is a channel for communicating back from retailers to suppliers (the Catalog Item Confirmation message CIC).”

As a sensible supplement to 1) and 2) this is a clear decision point for GDSN. However it stands or falls with retailers using that mechanism to give their feedback.

A glance at some of the mentioned “Negatives”:

“1) Implementation is complex for suppliers and retailers”

Without a doubt: A project has to set up the GDSN data model with its attributes, code lists and validation rules, implement the message formats and message choreography plus the technical inter­face to connect to a GDSN data pool. Even choosing the right attributes from several hundred ones within GDSN core and various extension areas is a challenge.

But instead of starting from scratch the customer uses LANSA “Data Sync Direct” (http://www.lansa.com/pim/), a lightweight PIM with focus on GDSN connectivity, containing a pre­build, out-of-the-box GDSN data model, generating the XML data formats and following the needed message choreography. This reduces the project complexity to its essential core: Choose and con­figure the needed attributes, data sources and mappings.

“2) Although GDSN defines a message standard, this is only mandatory to be used between data pools. … MDM/PIM/tool provider has to build an extra interface for each and every data pool he wants to connect his tool to. ...”

This is another issue losing its effort with the use of LANSA “Data Sync Direct” containing prebuild interfaces to both, the 1SYNC and the 1Worldsync “WS2” GDSN data pool. In this project the customer’s global home data pool is going to be the US 1SYNC GDSN data pool. Any recipient connected to another GDSN data pool, e.g. the 1Worldsync “WS2” in Germany is going to receive the data via pool-to-pool communication done in the background by the GDSN.

“3) Typically GDSN does not cover all the requirements a retailer has regarding data synchronization. Therefore retailers are often asking for additional product information from suppliers on different ways. Very obvious is that GDSN today does not yet cover B2C data. …”

Even with hundreds of attributes, the current GDSN data model focuses on B2B data exchange. In this project the additional textual B2C product information is split apart several additional attribute name / value pair attributes. Even though this mechanism gives flexibility to transport arbitrary data across the GDS network, an attribute value is restricted to 255 characters, which makes it hard trans­porting longer text fragments. 

The GDSN data model offers more options to implement such requirements, like the “Trade Item External Information” attribute group, allowing to link to data being available externally (e.g. via URL).
However the B2C requirements are an area which GS1 needs to give answers on by extending its GDSN standards suitably. Otherwise different projects would use GDSN specifically to transport such data with the result of individual solutions within GDSN.

In summary, the positive aspects outweigh. All requirements – even the more tricky ones – could be mapped onto GDSN data model and obviously it allows implementing the “one point of entry principle” for a global company also. We’ll have a look at the system once all requirements are implemented and product information is synchronized with European retailers using the GDS network. I’ll keep you posted!