GDSN  - What's Next?

Now that the GDSN community is in full swing of preparing for the update to Major Release 3, which is scheduled for May 2016, it's a good time trying to dare a glimpse into the future and wrap our minds around developments that, as we believe, are likely to become a focus of attention in master data synchronization over the next few years.

Notwithstanding the challenges and efforts ahead, Major Release 3 will be a big step forward. It provides many substantial improvements, some of which were long and eagerly yearned for, and moreover, we are convinced that it will open up the standard for broader adoption. So far, so good. But, what is next? If a standard doesn’t evolve, it’s dead. Thus, nobody should be surprised that there is room for improvement. The discussions that lead the way to Major Release 3 started many years ago, and meanwhile, new challenges came about that have not yet been addressed nor discussed, let alone solved.

These challenges arise from an overall need for greater agility and responsiveness in the supply chain which in turn demands the same from global data synchronization. Essentially, it all boils down to providing and processing

• more volatile data,
• more detailed and fine-grained data, particularly with more attributes,
• more consumer-targeted data,
• more interwoven and interdependent data,
• more data at an earlier stage of the product lifecycle,
• and more partially available or even premature data.

Moreover, these challenges get boosted by an increasing number of participants in the market, that all require access to product data, particularly

• more (and smaller) retailers,
• more verticals
• third-party logistics,
• e-commerce,
• search engines,
• mobile applications,
• and, before anything else, the end consumer.

So why do we think that the GDSN standard in its current form, even with Major Release 3, isn’t fit for these challenges? In business and in engineering there are often good reasons to do things exactly the way they're done, and surely one might be tempted to assume that this applies equally well to the GDSN. On the other hand, it’s occasionally a good idea to have a look beyond the horizon. After all, it is a certain fact that the GDSN community is not alone in its efforts to shuffle data back and forth. And if you look around, you’ll notice that the way synchronization is done in GDSN is not without alternatives. Of course, it’s a valid question to ask: Can’t we do it any simpler than with all that rigid and complicated choreography stuff?

But before we delve deeper into the present shortcomings of the GDSN, we should try to understand how it got there, and thus take a look at how it evolved historically. The GDSN was designed to pursue a “push-centric” messaging approach, where the relevant information is actively sent in the form of business messages. This approach got its roots in the EDI standards of the nineteen-eighties, namely in ANSI X12 and EDIFACT/EANCOM. These were mostly adopted for messaging schemas dealing with purchase orders (ORDERS) and invoices (INVOIC), where clearly a push-centric approach is legally advisable: Before an invoice can become due, it somehow must have been delivered. Similarly, a purchase order can only become binding after the supplier provably received it. In fact, if you need a certain level of guaranteed delivery, usually in the form of a confirmation receipt, then it is better to push the message to your business partner rather than to rely on them for pulling it. By the way, it is no surprise that in the aftermath of the greater adoption of EDI, an Internet-based transport protocol like AS2 evolved, which provides exactly such a kind of confirmation receipt, namely the MDN, on top of a push protocol.

There are several reasons, why the push-centric approach that was initially chosen for purchase orders and invoices, sometimes still makes perfect sense for master data synchronization. For example, when you deliver an update on a product item which is highly important for a retailer to know about, then, of course, you want to be able to prove that you did. In general, however, push-centric approaches tend to be stolid. Why? Because, when a sending party starts pushing a message, it cannot know the receiver’s most urgent demand, at least not at exactly that point in time.

This is what happens to a retailer in the GDSN when they submit an item subscription to the data pool where the pub-sub match results in hundreds of thousands of item notification messages, which is regularly the case when e.g. the subscription retrieves on a target market. The result is often a flood of messages jamming the line for hours or even days and there’s almost no chance of getting through with any other subscription during that time. If you urgently need the product data for another item at that point in time, you don’t have to be a genius to start dreaming of a URL where you could just download™ the desired item data instantaneously and on demand. Technically, what this dream is about is the ability to pull the information, hence a pull approach. And now you understand that the GDSN has implemented only the first half of a push-pull strategy. As they describe it perfectly well in this Wikipedia page: “On markets the consumers usually "pull" the goods or information they demand for their needs, while the offerers or suppliers "push" them toward the consumers.”

That’s why suppliers feel quite comfortable with the push-centric approach of the GDSN, and it’s also why the retailers feel the pain. We see it as inevitable that the GDSN needs to be supplemented with a pull approach. In other words, we believe that the GDSN needs to get its missing second half of the push-pull strategy. Recent ambitions of the GS1 like the “GTIN+ on the web” standard go exactly in that direction. “GTIN+ on the web” provides schemas for structured product information, very similar to the data structures in a GDSN item notification, but adhering to the rules of linked data. The crucial thing about linked data is, that every data object or “resource” as they call it, has its unique, permanent, and addressable location, namely a URL. Now with linked data, a product item or even a set of product items has the URL we dreamed of above, where you can just download the desired data from. It’s basically the idea behind the World Wide Web that we all know, where every page has a URL, just carried forward to the realm of information exchange between software systems.

In our opinion, it’s just a matter of “when”, not “if”, that data pools will pick up on these ideas.

Communication and sales promotion 2.0 – stationary retailers sit back and watch

Traditional retailers miss opportunities which good online communication and online sales promotions provides. Online retailers leverage this space for their own growth. Already small differences in the details can have an appreciable impact.

The evolution of online food draws an interesting picture. Emerging online retailers, often Internet pure-players (IPP), typically offer a very selective assortment like tea and coffee or muesli. They conquer a specific market segment, establish themselves and expand their range of products. Of course they show recognizable strengths in their execution of online communication and online sales promotions. At the same time they successively enhance their logistic as the business growths. Meanwhile traditional retailers work on closing gaps in the assortment, increase online-investments and start integrating their different sales and communication channels.

Stationary food retailers retain price leadership in food retailing

Traditional German food retailers still continue to lead the price competition in our observation. Their challenge is to transfer their efficient merchandize management and logistic processes into the online world, where they inevitably have to offer more services and still want to make profit. Store processes, that have been transferred onto the customer since decades, have to be done by the retailer again, like the physical picking of items during the shopping process. By introducing self-service supermarkets back in the 1960's, this was no longer done by the merchant behind the counter, but by the customer himself via pushing his shopping cart through the store. The gain in efficiency was for instance reflected in lower prices. But online retailing means to add services like picking and packing or a comfortable home delivery. Especially customer oriented fulfilment services became an important competitive advantage during last years. As it is very hard to charge extra fees for additional services in the German grocery market, retailers need to scale this business and find new approaches for making it viable. Established retailers will find ways to handle such challenges.

Make better use of online options for communication and sales promotion

However, we often notice that traditional food retailers neglect their online communication and sales promotion in the course of the effort described above. For example, a young online retailer advertises a key value item,  JACOBS Krönung 500g, for 6,59 EUR using Google. At the same time, a stationary retailer runs a price promotion for the same item at 4,29 EUR - a difference of 2,30 EUR or 35 percent. As the Google search result does not bring up this promotion, the potential customer will not be informed about this offer and probably shop the coffee for 6,59 EUR.

Example: JACOBS Krönung 500g - price advantage and customer approach

In this example, the stationary retailer could render his promotion interpretable for search engines by utilizing the shared markup vocabulary (http://schema.org). He could explicitly bring up the promotion price, product availability and customer feedback. The algorithms of popular search engines reward and typically use such kind of information when preparing search results.

Approach customers online at the right time and stage in their buying process

The retailer gains a digital version of the popular weekly hand-out without having to place a Google ad. The customer is already targeted during his Google search, long before visiting the online shop when the buying decision was already made. Additionally, a consumer will hardly buy the coffee online for 6,59 EUR if he only has to spend 4,29 EUR during the next shopping trip in the store or online. The retailer can add such kind of online activities as added value to the regular dialogs and negotiations with his suppliers.

Reliable master data is the basis

There are many ways to be more present online and expand the business. The basis for us is reliable master data. We love to help you to properly set up your master data and leverage business value.

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