Automatic Classification According to eCl@ss

The product classification system eCl@ss has established itself in many industries as the preferred standard. Initiated and funded by Germany's major companies and later adapted by the federal procurement and some of the federal states, eCl@ss today plays an increasingly leading role in the implementation of electronic commerce for SME (small and medium-sized enterprises). This being said, the classification of product master data via eCl@ss is by no means trivial. eCl@ss is more than just a product group structure and the classification of items in product groups may be itself already an endeavor hardly manageable without automation, particularly with data sets that go into the hundred thousands or even millions.

Yet whoever wants to classify product master data entirely via eCl@ss has to consider the so-called feature lists on top. Also, there is no operating eCl@ss correctly and consistently without supplying all articles with a customs tariff number. We'll come to that in a later blog post.

Classifying on the "green field"

Naturally, here as elsewhere applies: Every journey begins with the first step. Every eCl@ss introduction should start with a product category assignment. On the one hand, it can be quite useful for the eCl@ss introduction if another product group system (a company-owned in-house one, for example) is already in place. On the other hand, as a point of departure this can tempt into going the wrong route, namely, into trying to map the eCl@ss category from the existing product group. At first, this approach appears obvious and sensible, as it makes use of already available information. In the long run though often entire departments become occupied with the creation of mapping tables intended to map the product groups onto each other. At the end it typically turns out that such a mapping can hardly or not be defined at all, unless the granularity of the two product group systems are incidentally identical up to the last detail.

Let's illustrate this with a specific example.
Assuming, a company’s product master data were classified according to an internal product group system. This system would, for example, separate flow pumps into axial, diagonal and radial pumps. Such product grouping may well occur in industrial practice.

eCl@ss, however, offers very different categories:

• Submersible pump
• Circulation accelerator pump
• Ship lift (pressure increase)
• Centrifugal pump with shaft seal
• Centrifugal pump with canned motor
• Centrifugal pump with magnetic coupling
• Other unspecified centrifugal pump

Obviously, there is no correlation between the two systems. The product group in eCl@ss is significantly determined by the sealing system (shaft seal, magnetic coupling , ...) of the centrifugal pump, while the design (axial, diagonal or radial) is only laid out as an additional feature. In our assumed example however, the design is crucial for the definition of the product group itself. No matter how you look at it: the eCl@ss category can not be derived, at least not as long as one only considers the internally classified product group. Unfortunately, in practice this often leads to "pragmatically" attributing a shaft seal to each and every pump. Alternatively and even worse, all pumps may straight away be subsumed under "Other unspecified centrifugal pump". It should be clear, that this "solution" is far from being pragmatic, actually even more than botchy.

The answer to this problem is relatively simple though. As well as considering the internal product category, all available information about the article needs to be evaluated. If for example the article description includes the terms "magnetically coupled", then this information should obviously be employed instead of being ignored. To effectively implement this approach, a software is needed that can utilize existing master data for automatic classification using machine learning algorithms. Roughly speaking, this principle uses known examples (learning set) to calculate how the occurrence of the term "magnetically coupled" as part of the article description affects the (conditional) probability, that the article in question is indeed a "centrifugal pump with magnetic coupling". The calculated value is then used to predict the remaining, as yet unclassified articles. In fact, algorithms for automatic classification work even quite satisfyingly if there hasn't been an internal product group in use prior to the introduction of eCl@ss.

The next blog post will discuss how methods of automatic classification can optimize master data quality.

Holger Joest

The EU Regulation 1169/2011 on Food Information for Consumers vs. GDSN - A Closer Look into Nutrition Declaration

In this article of our blog series on the European regulation 1169/2011 on the provision of food information to consumers, I want to discuss the nutrition declaration in closer detail with reference to some actual examples.

What does the new EU regulation say about nutrition declaration?

Here are two excerpts from the introductory statement:

• "(35 ) To facilitate the comparison of products in different package sizes, it is appropriate to retain the requirement that the mandatory nutrition declaration should refer to 100 g or 100 ml amounts and, if appropriate, to allow additional portion-based declarations. Therefore, where food is prepacked and individual portions or consumption units are identified, a nutrition declaration per portion or per consumption unit, in addition to the expression per 100 g or per 100 ml, should be allowed. ... "
• "(41) To appeal to the average consumer and to serve the informative purpose for which it is introduced, and given the current level of knowledge on the subject of nutrition, the nutrition information provided should be simple and easily understood. ..."

In the subsequent articles the mandatory information is explained in more detail. The following is a very abbreviated summary:

• Article 30 defines the mandatory content of the nutrition declaration. These mandatory data are called "BIG 7" (the nutrition declaration with the additional specification of fiber is called "BIG 8"):
  "... The mandatory nutrition declaration shall include the following:
  (a) energy value; and 
  (b) the amounts of fat, saturates, carbohydrate, sugars, protein and salt.  ..."
• Article 32 defines the amount to which the mandatory nutrition declaration must refer: "...Expression per 100g or per 100 ml
  (1) The energy value and the amount of nutrients referred to in Article 30 (1)-(5) shall be expressed using the measurement units listed in Annex XV.
  (2) The energy value and the amount of nutrients referred to in Article 30 (1)-(5) shall be expressed per 100g or per 100ml. ..."
• Article 33 defines optional additional nutrition declaration per unit of consumption: 
  "... Expression on a per portion basis or per consumption unit. 
  (1) In the following cases, the energy value and the amounts of nutrients referred to in Article 30 (1)-(5) may be expressed per portion and/or per consumption unit, easily recognisable by the consumer, provided that the portion or the unit used is quantified on the label and that the number of portions or units contained in the package is stated:
  (a) in addition to the form of expression per 100 g or per 100 ml referred to in Article 32 (2); ..."
• Article 34 defines the presentation. " ... (1) The particulars referred to in Article 30 (1) and (2) shall be included in the same field of vision. They shall be presented together in a clear format and, where appropriate, in the order of presentation provided for in Annex XV.
  (2) The particulars referred to in Article 30 (1) and (2) shall be presented, if space permits, in tabular format with the numbers aligned. ..."
  The nutritional information is to be presented as follows (according to Annex XV "EXPRESSION AND PRESENTATION OF NUTRITION DECLARATION " ): " ... The units of measurement to be used in the nutrition declaration for energy (kilojoules (kJ) and kilocalories (kcal)) and mass (grams (g), milligrams (mg) or micrograms (µg)) and the order of presentation of the information, as appropriate, shall be the following:"
  - energy (kJ/kcal), mandatory ("BIG7")
  - fat (g), mandatory ("BIG7")
  of which:
    - saturates (g), mandatory ("BIG7")
    - mono-unsaturates (g), optional
    - polyunsaturates (g), optional
  - carbohydrate (g), mandatory ("BIG7")
  of which:
    - sugar (g), mandatory ("BIG7")
    - polyols (g), optional
    - starch (g), optional
  - fibre (g), optional (additional information of the "BIG8")
  - protein (g), mandatory ("BIG7")
  - salt (g), mandatory ("BIG7")
• For the nutrition information on "salt", the regulation defines:
  " ... ( 37) Since one of the objectives pursued by this Regulation is to provide a basis to the final consumer for making informed choices, it is important to ensure in this respect that the final consumer easily understands the information provided on the labelling. Therefore it is appropriate to use on the labelling the term 'salt' instead of the corresponding term of the nutrient 'sodium'. ..."
  Annex I "Specific definitions" defines how the value for salt is calculated based on sodium: 'salt' means the salt equivalent content calculated using the formula: salt = sodium × 2,5".

When does the nutrition declaration become effective?

The nutrition declaration is mandatory from 13/12/2016 onwards. If voluntary declarations are being provided before this date, they have to correspond to the regulation from 13/12/2014 onwards.

Product examples and their mapping in GDSN

Looking at product examples today, the format and presentation of nutritional values can be more or less divided into three classes:

1. "single-column" - the strictly mandatory declaration, i.e. the nutritional information per 100 g or 100 ml
2. "double column" - in addition to the mandatory declaration, information is provided for every individual portion size
3. c. "triple column" - the mandatory declaration, the portion size and an additional percentaged quantity, based on a daily intake standard (reference standards for the daily intake are listed in annex XIII of the regulation). On these products, the "1+4 model", developed by the German Federal Ministry of Food, Agriculture and Consumer Protection, is often additionally applied. This model declares the energy content and the amounts of fat, saturates, sugar and salt per serving as well as the percentage of its calories and nutrients in relation to the recommended daily intake.

Additionally, the "Representation in the GDSN data model" shows how these informations are transported throughout the GDSN. It also illustrates how much interpretative and processing work is needed for a representation apart from just the data transfer task.

Product example 1 and representation in the GDSN data model

"Single-column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt.

Product example 2 and representation in the GDSN data model

"Single-column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt, plus the "1+4 model". 

Portion size is one 250ml serving.

Product example 3 and representation in the GDSN data model

"Double column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt. 

Portion size is one biscuit (24g).

Product example 4 and representation in the GDSN data model

"Double column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt.

Additionally, vitamin and trace element information are being listed as well as their percentage in relation to the recommended daily intake.

Vitamin B1 is not specified on the GDSN UNInfoods list.

The "1+4 model" is located on the front of the packaging.

The portion size is based on a prepared serving of cereal with milk.

Product example 5 and representation in the GDSN data model

"Double column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt, plus the "1+4 model". 

Portion size is one 25g waffle.

Product example 6 and representation in the GDSN data model

"Triple column", Big 8 complete, sequence standards according to the EU regulation not met, lists sodium instead of salt. 

Portion size contains five biscuits (ca. 34g).

EU regulation conformity of the product examples

It is striking that none of the considered examples is EU regulation compliant yet. On all products the voluntary nutrition declaration according to directive 90/496/EEC in form of the "Big 8" (energy value, protein, carbohydrates, sugar, fat, saturated fat, fiber, sodium) is supplied. However, their sequence is changed in the new table according to the EU  regulation: Fiber becomes optional and salt is no longer listed as sodium.

Nutritional value coding in the GDSN data model

The nutritional values of the product examples were coded following  the GS1 recommended codes and attribute applications (see the following comment on salt). They therefore represent a "best practice" use of GDSN for the nutritional information.

Yet the example of "sodium" already indicates the band width of variations when it comes to data management. The EU regulation compliant information would be "salt" (code "SALTEQ"). A conversion (salt = 2,5 * sodium) on part of the data recipient would appear to be the most pragmatic solution. The EU regulation holds responsible whoever registers or changes the product information though.

Many product data will have been registered according to the GS1 recommendations for the use of GDSN alongside the new EU regulation data. But there will also be data suppliers who will provide product data that are EU regulation compliant, but depart from the GS1 recommendation. Next to different applications of attributes, codes for single nutrition values can also vary.

Here, for example, are the possible alternatives for protein declarations:

PRO-, protein, total; method of determination unknown or variable (the GS1 recommendation for protein coding)

Possible other codes:

PROA, protein, total; determined by direct analysis

PROANI, protein from animal sources

PROCNA, protein, total; calculated from amino

PROCNP, protein, total; calculated from protein

PROCNT, protein, total; calculated from total nitrogen

PROPLA, protein from plant sources

PROTAN, protein, animal

PROTPL, protein, plant

Conclusion

The new  regulation ensures that the up to now largely voluntary nutrition information on products will become obligatory for the entire European Union. Information will be more comprehensive, uniform and more intelligible and nutrition information will be made available for stationary as well as online trading. 
Until this is achieved by the end of the transition period in 2014 though, a lot of implementation efforts are still waiting.

The Mandatory Information of the EU Regulation 1169/2011 on Food Information for Consumers vs. GDSN

We are currently working on a project where GDSN product data, especially those relating to the new European regulation, are being received and edited into consumer-friendly formats for an online shop. I would like to highlight this challenge in the second article of our blog series on the EU regulation No 1169/2011.

What characterises the mandatory information of the new European  regulation in relation to a real product example?

Lets recall article 9, "List of mandatory particulars" (see also http://themdmblog.blogspot.de/2013/12/eu-regulation-11692011-on-provision-of.html ):

1. The name of the food ("Product Name" in the illustration: "Double-filled biscuits with cocoa cream filling 46%".
2. The list of ingredients ("Ingredients" in the illustration): "Ingredients: flour, sugar,..."
3. Any ingredient or processing aid causing allergies or intolerances ("Allergens" in the illustration): "May contain traces of: Soy". The additional nutritional information "Suitable for vegetarians" is no mandatory declaration according to the European  regulation.
4. The quantity of certain ingredients or categories of ingredients. The product example provides here no more detailed declaration in its list of ingredients 
5. The net quantity of the food: ("Net Content" in the illustration): "400 g".
6. The date of minimum durability or the 'use by 'date ("Best Before Date" in the illustration)
7. Any special storage conditions and/or conditions of use ("Storage Instructions"in the illustration): "Protect from heat. Store in dry conditions"
8. The name or business name and address of the food business operator as well as
9. The country of origin or place of provenance where provided for ("Origin / Manufacturer" in the illustration)
10. Instructions for use (if necessary) - not relevant in case of the product example
11. With respect to beverages containing more than 1,2 % by volume of alcohol, the actual alcoholic strength by volume - not relevant in case of the product example
12. A nutrition declaration (mandatory only from 13. December 2016) ("Nutrition Info" in the illustration)

Who will be affected by the European regulation?

European  regulation applies to industry and commerce, both stationary stores and online stores.

The product example is largely European regulation compliant and therefore meets its stationary trade standards: the customer can take the product into his hands and decide on the basis of the information printed on the package whether it fits his needs.

How does the online shop get the relevant data via GDSN though?

Let's look, for example, at the allergy information on the product example: "May contain traces of : Soy". The GS1 manual for the use of GDSN for the European  regulation makes the following recommendation:

In the GDSN data model, there is the repeatable attribute group "foodAndBeveragesAllergen" with which a lot of the allergens contained in a food product can be described. 

The attributes of this group are defined as follows:

• allergenSpecificationAgency - organisation that defines the allergen information 
• allergenSpecificationName - name and version of the definition informing the transmitted allergen information 
• allergenTypeCode - code that identifies the allergen contained 
• levelOfContainment - code that specifies the amount of the allergen contained 

Using our specific example, this will look as follows (attribute = value -> explanation)

• allergenSpecificationAgency = EU -> pre-defined default referring to the recommendation 
• allergenSpecificationName = 1169/2011 -> pre-defined default  referring to the recommendation 
• allergenTypeCode = AY -> GDSN code list code "allergenTypeCode"
• levelOfContainment = MAY_CONTAIN -> GDSN code list code "Level of Containment Type Code"

In this example, the actually relevant allergen information is transmitted via the two codes "MAY_CONTAIN AY" contained in the pre-defined GDSN code lists. 
So what do these codes actually mean?
As a code of the "allergenTypeCode" code list, AY is defined as: "AY: Refers to the presence of soybeans and their derivatives in the product, as listed in as listed in the regulations specified in AllergenSpecificationAgency and AllergenSpecificationName". Or, to put it simple: "soy".

As a code of the "levelOfContainment" code list, MAY_CONTAIN is defined as: "The substance is not intentionally included, but due to shared production facilities or other reasons, the product may contain the substance". Or, to put it simple: "can contain".

How is this information contained in the GDSN Catalog Item Notification (CIN) message which any data recipient gets from the GDSN data pool? 

In our example it looks, in a highly abridged version, as follows:

What is necessary to format this for the online shop?

The task is now (in addition to the technical details of the GDSN data pool connection and transformation of the GDSN messages, which I will not look at in this article) to extract the consumer-friendly notice "Can contain traces of: soy" from the GDSN compliant product information "MAY_CONTAIN: AY".

This means that for the relevant codes of the GDSN code lists the desired text fragments must be deposited and mapped. In our example these would be text fragments for the notice if an allergen is contained ( "Level of Containment Type Code"):

• "MAY_CONTAIN" => "May contain traces of:" 
• "CONTAINS" => "Contains:"
• "FREE_FROM" => "Does not contain:"

As well as the text fragments or declarations for potentially allergy-causing substances ("Allergen Type Code") - here are some examples:

• "AX" => "gluten"
• "AY" => "soy"
• "AS" => "sesame"
• "SH" => "hazel"

Following this final text module mapping, the consumer-friendly text passages for display in the online shop can be extracted from the coded GDSN product information:

There are of course quite a few more delicacies regarding the mandatory product declarations according to the new European regulation - we will come back to them in our in our next article ...

EU Regulation 1169/2011 on Food Information for Consumers in Brief Overview

In response to different food scandals of younger history the EU issued the regulation 1169/2011 as a directive on the provision of food information to consumers.

This regulation states

• General goals, as in chapter II, article 3: “ The provision of food information shall pursue a high level of protection of consumers’ health and interests by providing a basis for final consumers to make informed choices and to make safe use of food, with particular regard to health, economic, environmental, social and ethical considerations.”.
• Basic requirements, as in chapter III, article 7: “(1) Food information shall not be misleading, … (2) Food information shall be accurate, clear and easy to understand for the consumer. …”.
• As well as responsibility for the supplied information.

         In addition the regulation contains a number of specific, detailed requirements on mandatory information, the presentation and placement on food packaging, guidelines for language used and labeling as like as lists of ingredients, additives, allergens which may cause intolerances or allergies etc.

List of mandatory particulars:

1. The name of the food;
2. The list of ingredients;
3. Any ingredient or processing aid listed in Annex II or derived from a substance or product listed in Annex II causing allergies or intolerances used in the manufacture or preparation of a food and still present in the finished product, even if in an altered form;
4. The quantity of certain ingredients or categories of ingredients;
5. The net quantity of the food;
6. The date of minimum durability or the ‘use by’ date;
7. Any special storage conditions and/or conditions of use;
8. The name or business name and address of the food business operator referred to in Article 8(1);
9. The country of origin or place of provenance where provided for in Article 26;
10. Instructions for use where it would be difficult to make appropriate use of the food in the absence of such instructions;
11. With respect to beverages containing more than 1,2 % by volume of alcohol, the actual alcoholic strength by volume;
12. A nutrition declaration (becoming mandatory on 13^th of December 2016).

This directive affects both manufacturers and retailers. It applies to food business operators at all stages of the food chain, where their activities concern the provision of food information to consumers. Stationary shops as like as online shops. 
It becomes effective 13^th of December 2014. Thus it is only 12 month time, to learn about the requirements and get the implementation done.

How GDSN may help with these requirements is part of upcoming blog articles.

Source: REGULATION (EU) No 1169/2011 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 October 2011

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!

It’s a recommendation – not a standard!

Experiences with GS1 Standards for Data Exchange in Germany for Healthcare Industry

Like your navigation system in the car warning you to stick to traffic regulations and not follow the instructions blindly, the same applies if you enter unknown territories in IT. In our MDM world I was asked to cross an “unknown territory”, namely doing GS1 GDSN compliant item data transformation for healthcare industry.

Starting with that it looked pretty straightforward: The data provided was CSV, the result expected GS1 XML item messages. The customer told me there’s a GS1 Germany “Healthcare Implementation Recommendation on Item Data Exchange”. Good, well documented area.

But stop: The document is based on version GS1 XML version 2.3. Version 2.3? That was issued in 2008 – meanwhile we’re five versions ahead at 2.8! Lucky I was – only a few uncritical attributes seemed to be missing. No problem, for such cases GDSN defines some kind of backdoor to the highly standardized data model, so called “attribute/value pairs” to transport individual data.

But stop again: Where is this attribute value pair structure described in the “Healthcare Implementation Recommendation”? Nowhere! So, no backdoor, no attributes – the customer dropped them from his data model mapping requirement list.

I continued mapping the data: Healthcare industry uses eCl@ss classification extensively to categorize products and add additional attributes. Categorization is ok – GDSN allows for lots of additional classifications. But again, more attributes to transport – having the missing attribute/value structure still in mind? The “Healthcare Implementation Recommendation” gives a helping hand, the solution described is creative: The GDSN “Classification Description” field is used to transport the eCl@ss attributes. As repeated structure. Defining a CSV usage style for this misused “Classification Description” attribute. What?

There are two comments on that: 1) My personal preference: We’re in a XML world – I don’t like mixing that up with CSV-style values. 2) The hard fact: GDSN validation rule 108 (“For each supported classification agency a GTIN may only have one classification code”) would disallow such item data to go into a GDSN pool.

Stop again: The customer required this eCl@ss data to be transported. That was put on the issue list – maybe the GDSN data pool provider de-activates validation rule 108 to get that data stored in the data pool…

Some first tests against a GDSN data pool with transformed single items showed another smaller problem: The recommendation does not define any date or timestamp related to the item. GDSN defines four mandatory dates and timestamps. Remained stuck again. However, this hurdle was taken pragmatically by adding some generated dates and timestamps, the date of transformation will do!

With the data model mapping done, the final step was assembling the item hierarchies. Another look into the “Healthcare Implementation Recommendation” explained that as “…Due to the fact there’s no hierarchy being built, the CIN should contain the base item and then the next higher level.” Did I say “What?” before? Think so! The GDSN standard defines item hierarchies always being set up top-down: Starting e.g. with a pallet and then “unpacking” the contained items until the base item is reached. With the recommendation implemented, the hierarchy is set up vice versa. A first test against a GDSN data pool resulted in weird error messages: It looked like no one on the pool provider side expected data suppliers to send hierarchies turned around.

Final stop for this blog post: I added the wrong hierarchy to the issue list where the eCl@ss problem already resided… this needs to be sorted out with the customer and GS1 as this blows pragmatic solutions. Keep posted for an update on this.

So, be careful, if the standard travel guide describes a bridge to be used, but your navigation system recommends using a rowing boat ferry where your car can be transported upside down easily.

Predictions on GDSN and MDM for 2013

Do you remember my last years posting "9 Predictions on GDSN and MDM for 2012"? In the following I will try to see where we are and what I am personally expecting from 2013 ...

1. GDSN will overcome the national Data Synchronization standards and become the real global Datasync standard
Has this already happened in 2012? It depends on your view - for sure GDSN is not yet fully established in whole europe but the european communities are all working on this. In Germany industry and retail is working hard on migrating from SINFOS to GDSN (see here). Austria is starting a complete new initiative to launch GDSN (have a look here). GS1 Finland is preparing to switch from SINFOS to GDSN (see here). GS1 Denmark too. France, Italy and Spain are already on GDSN. Even GS1 UK is pushing hard for GDSN even though the major UK retailers are still not beyond pilot. So the majority of europe is at least working seriously to adopt GDSN.

For sure it will take some more time until whole europe will show reasonable adoption of the GDSN. In germany the official goal is to have the whole migration to GDSN finished by the end of 2013. I would not be surprised if it will take until mid or end 2014. But then it will be accomplished.

2. Master Data Management also gets implemented by European retailers
What are twelve month for such an important business decision? European retailers definitely have the awareness that there is a huge business need to introduce Master Data Management as a new business process ... At least that is my perception when I am talking to european retailers. To support my perception I just tried to find some publications on the internet on the topic - but looks quite difficult. There is not much published out there. What I found was some success stories like Heiler on EDEKA or Imperia on METRO, and a very old blog post from Gartner here. But some more general information or survey? Nothing right now ... So in 2013 I definitely have to collect some more information on that topic, help always welcome ;-)

3. Retailers build their own portals to gather item master data on top of GDSN to have a free solution for suppliers and to collect data beyond the standards – and this will burst the usage of GDSN
At least Casino, Edeka, Metro Group, Praktiker and REWE Group (not sure whether this is a complete list) are using the 1WorldSync service to offer their suppliers a free portal to provide their master data to them. Other retailers choose other solutions (eg. Tesco uses a service from Brandbank) and I am pretty sure that there are also other retailers out there who have build their own supplier portals offering options to let suppliers provide them their product information.

How this helps GDSN adoption? Retailers who are offering their suppliers a free channel to provide their item master data to them as an alternative to GDSN are able to rollout this to their suppliers very quickly and thereby they are getting their ROI for the electronic data sync process much quicker then if they would only rely on GDSN. And this is what counts.

4. E-Commerce in Europe becomes the driver for MDM and GDSN in retailers &
5. B2C item information will become integral part of GDSN
EU Food Information Regulation (1169/2011) obviously became in 2012 a driver for suppliers and retailers in grocery to think about how they can get this information into the online shops. A good impact analysis of this regulation can be found here. As this regulation will take effect in December 2014, industry and retail will be busy in 2013 and 2014 to solve the challenges.

GS1 is pushing here with their "B2B2C"-Initiative a lot to solve those challenges based on the current GDSN infrastructure. This approach from my perspective is very reasonable and gives retailers the benefit of only having to implement one interface (MDM at a retailer is then a prerequisite) and suppliers the freedom either to also implement MDM and GDSN or to just use a data capture service provider to fulfill the requirements of retailers.

The risk for this approach is that retailers really have to implement it now (in 2013). Otherwise they might be tempted in 2014 to take a shortcut and favor a model like in UK where retailers are mandating that B2C data has to be captured by Brandbank. This is a free service to retailers but has to be paid by industry. And retailers might be tempted even not to touch their IT infrastructure but simply feed that data only directly into their online-shop and not getting any other benefits out of this data. 

6. Stationary retailers will learn from Amazon that the electronic supply-chain is key for success
Hmmm, any update on this? I do not know ... just a personal note - I learned that grocery online shopping is different from shopping other goods online. I never did grocery online shopping until REWE started their home delivery service here in cologne. Even though the online shop is not yet as good as you would expect it today (product information, images, search, ... - Amazon sets the bar quite high) the whole service is great! Why? It is home delivery! Since they started their service back in October 2012 I have never been again in a supermarket!

7. The GS1 system demands an integrated solution for supplier data, item master data and transactional data
I have not seen anything happing in that area. Did you?

8. Gepir will be abandoned
I have not seen anything happing in that area. Did you?

9. GDSN at the tipping point - Not for profit vs. commercial services
2012 was the tipping point - with the merger of 1SYNC and SA2 Worldsync there is only one real global data pool left and that is owned by GS1 US and GS1 Germany. Now most of the GDSN is controlled by a not for profit organisation. This should remove all the barriers and politics within the network and hopefully help to make data synchronisation a lot easier. Looking forward to 2013!

2013 will become again very interesting in the areas of MDM and GDSN!

Happy New Year!