GDSN – Wie geht es weiter?

Jetzt, da in der GDSN – Community die Vorbereitungen für das im Mai 2016 geplante Update auf das Major Release 3 in vollem Gange sind, ist es eine gute Gelegenheit, den Blick auf die Zukunft zu richten und sich ein paar Gedanken über solche Themen zu machen, die in Sachen Stammdatensynchronisation unserer Auffassung nach in den nächsten Jahren von zentraler Bedeutung sein werden.

Mal abgesehen von den Herausforderungen und Anstrengungen die mit diesem Update einhergehen, ist das Major Release 3 ohne Zweifel ein großer Schritt nach vorn. Es bringt zahlreiche wesentliche Verbesserungen, auf die man teilweise schon lange und sehnsüchtig gewartet hat und es wird unserer Auffassung nach ganz entscheidend sein für eine weitere Verbreitung des GDSN in andere Branchen. So weit, so gut. Aber, was kommt danach? Ein Standard, der sich nicht weiterentwickelt, ist tot. Es sollte daher auch niemanden überraschen, wenn es Spielraum für Verbesserungen gibt. Die ersten Diskussionen, die der Entwicklung des Major Release 3 vorausgingen, wurden bereits vor vielen Jahren geführt, und in der Zwischenzeit sind neue Herausforderungen hinzu gekommen, die bisher weder angegangen, noch diskutiert, geschweige denn gelöst wurden.

Tauziehen

Diese Herausforderungen ergeben sich aus der Notwendigkeit zu immer größerer Flexibilität und Geschwindigkeit in der Lieferkette. Das Netz zur weltweiten Synchronisation von Artikelstammdaten muss sich diesen Herausforderungen stellen. Im Wesentlichen läuft alles hinaus auf die Bereitstellung und die Verarbeitung von

  • sich permanent ändernden Daten,
  • hochgradig detaillierten Daten, insbesondere solche mit vielen Attributen,
  • mehr und mehr verbraucherrelevanten Daten,
  • stärker miteinander verwobenen und aufeinander aufbauenden Daten,
  • Daten, die bereits in einem früheren Stadium des Produktlebenszyklus relevant sind,
  • und teilweise sogar von noch unfertigen Daten.

Darüber hinaus werden die Herausforderungen verstärkt durch eine stetig wachsende Zahl von Marktteilnehmern, die Zugriff auf Produktdaten benötigen, insbesondere

  • mehr (und kleinere) Händler,
  • weitere Branchen,
  • Logistikunternehmen,
  • E-Commerce,
  • Suchmaschinen,
  • Mobile Apps,
  • und – nicht zuletzt – der Endverbraucher.

Warum wir denken, dass der GDSN-Standard auch mit dem Major Release 3 noch nicht für die neuen Herausforderungen gerüstet ist? In Wirtschaft und Technik gibt es hin und wieder gute Gründe, warum Dinge exakt so gemacht werden müssen wie sie gemacht werden. Man könnte annehmen, dass das auch im Falle des GDSN so ist. Auf der anderen Seite ist es jedoch manchmal ratsam, einen Blick über den Horizont zu werfen. Schließlich liegt es auf der Hand, dass die GDSN-Community nicht die einzige ist, die sich mit dem Hin- und Hersenden von Informationen beschäftigt. Und wenn man sich umschaut, findet man durchaus auch andere Ansätze als die, die wir vom GDSN her kennen. Die Frage ist schließlich berechtigt: Muss der Austausch von Stammdaten mit Hilfe einer so starren und komplizierten Choreografie erfolgen, oder geht es nicht auch einfacher?
Bevor wir aber tiefer in die Materie eindringen, sollten wir versuchen zu verstehen, wie das GDSN entstanden ist und warum es so ist, wie es ist. Das GDSN verfolgte von Anfang an einen push-zentrierten Ansatz, bei dem Nachrichten aktiv von einem Unternehmen zum anderen “gepusht” werden. Dieser Ansatz hat seine Wurzeln in den EDI-Standards der achtziger Jahre, nämlich in ANSI X12 und EDIFACT/EANCOM. Diese wurden vor allem für elektronische Bestellungen (ORDERS) und Rechnungen (INVOIC) eingesetzt. Bei diesen Nachrichtentypen ist ein push-zentrierter Ansatz zweifellos sinnvoll, allein schon aus rechtlichen Gründen: Bevor eine Rechnung fällig werden kann, sollte sie erst einmal dem Empfänger zugestellt worden sein. Analog kann eine Bestellung nur dann als verbindlich gelten, wenn der Lieferant sie vorher überhaupt erhalten hat. Will man eine garantierte Zustellung von Nachrichten sicherstellen, im Wesentlichen also eine Art Empfangsbestätigung, dann ist es natürlich einfacher, die Nachricht aktiv an den Geschäftspartner zu senden und nicht etwa darauf zu warten, dass er sie sich abholt. Interessant übrigens, dass im Zuge der immer größeren Verbreitung von EDI, sich mit dem AS2-Protokoll ein Internet-basiertes Verfahren durchgesetzt hat, das genau solch eine Empfangsbestätigung bietet, nämlich die MDN, und das natürlich auf der Basis eines Push-Protokolls.

Es gibt auch einige Gründe, warum der push-zentrierte Ansatz, der zunächst für Bestellungen und Rechnungen gewählt wurde, in einigen Situationen auch für die Synchronisation von Stammdaten sinnvoll ist. Zum Beispiel, wenn Sie eine geänderte Information zu einem Produkt übermitteln, über die der Händler unbedingt Bescheid wissen muss, dann möchten Sie anschließend auch in der Lage sein, beweisen zu können, dass Sie die Information übermittelt haben. Im Allgemeinen haben push-zentrierte Ansätze jedoch den Nachteil, dass sie eher schwerfällig sind. Warum? Weil ein Absender, der begonnen hat Nachrichten zu schicken, nicht mehr darauf reagieren kann, wenn der Bedarf des Empfängers sich zwischenzeitlich geändert hat. Was das bedeutet kann man z.B. dann beobachten, wenn ein Händler eine GDSN-Subskription an seinen Datenpool richtet, und der anschließende Pub-Sub-Match Hunderttausende von Artikelnachrichten zur Folge hat. Das ist regelmäßig der Fall, wenn zum Beispiel ein Zielmarkt abgerufen wird. Das Ergebnis ist dann eine Flut von Nachrichten, die die Leitungen oft für Stunden oder sogar Tage verstopft. Solange diese Situation anhält, gibt es für den Händler kaum eine Chance, parallel andere Produktdaten abzufragen.

Wenn Sie gerade in der Position des Händlers sind und dringend Produktdaten zu einem anderen Produkt benötigen, dann ergibt sich eine Idee geradezu von selbst: Dass man sich nämlich eine URL wünscht, wo man die benötigten Artikeldaten spontan bei Bedarf einfach herunterladen kann. Technisch gesehen ist ein solches „bei-Bedarf-einfach-herunter-laden-können“ eine Pull-basierte Kommunikation. Und an dieser Stelle wird klar, dass im GDSN nur die eine Hälfte einer Push-Pull-Strategie implementiert wurde. Ein Abnehmer hat das Bedürfnis, sich Daten spontan bei Bedarf holen zu können („pull“), während ein Lieferant die Daten tendenziell lieber versendet („push“). Eine gute Push-Pull-Strategie sollte mit beiden Anforderungen umgehen können.

Lieferanten fühlen sich übrigens meistens ganz wohl mit dem push-zentrierten Ansatz des GDSN. Es sind vielmehr die Händler, die Bauchschmerzen damit haben. Wir sehen es als unvermeidlich an, dass das GDSN um Fähigkeiten zur Pull-Kommunikation ergänzt wird. Neuere Initiativen der GS1 wie etwa „GTIN+ on the web“ gehen genau in diese Richtung. „GTIN+ on the web“ bietet Schema-Definitionen für strukturierte Produktinformationen, sehr ähnlich der Catalogue Item Notification im GDSN, aber den Regeln des Linked Data entsprechend. Das Entscheidende an Linked Data ist, dass jedes Datenobjekt bzw. jede „Ressource“, wie es dort genannt wird, hat seine eindeutige und dauerhafte Adresse hat, nämlich eine URL. Mit Linked Data erhält man genau die URL zum „einfach-herunter-laden-können“, die wir uns oben gewünscht haben. Es ist im Grunde die Idee hinter dem World Wide Web, so wie wir es alle kennen, in dem jede Seite eine URL besitzt. Hinzu kommt lediglich, dass die Idee auf den Informationsaustausch zwischen Software-Systemen angewendet wird.

Wir sehen es als eine Frage des „Wann“ und nicht etwa des „Ob“, dass Datenpools diese Ideen aufgreifen und umsetzen werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.