Genutzte (GS1) Standards in der Blockchain

06.12.2018

In meinem ersten Blogbeitrag – entstanden während der Entwicklungsphase – bin ich darauf eingegangen, wie nützlich Standard in Blockchains sind. Dabei habe ich skizziert, welche Standards in unserem Palettentausch-Praxistest voraussichtlich zum Einsatz kommen sollen – und dies haben wir auch so umgesetzt! Zur Sicherstellung einer möglichst hohen Skalierbarkeit, Interoperabilität und Marktakzeptanz hat sich das Konsortium auf folgende wesentliche Standards verständigt:

o GLN (Global Location Number) zur Identifikation der Tauschpartner

o GRAI (Global Returnable Asset Identifier) zur Identifikation der Europaletten

o GDTI (Global Document Type Identifier) zur Identifikation der Palettenscheine

o EPCIS und CBV (Core Business Vocabulary) als Datenmodell für die in der Blockchain gespeicherten Event-Transaktionen inkl. standardisiertem Vokabular

Die folgende Abbildung veranschaulicht die Einbettung dieser Standards in die digitalisierte Palettenschein-Lösung. Wichtig ist in diesem Zusammenhang, dass Standards in unternehmensübergreifenden Anwendungsfällen immer einen Mehrwert bringen - unabhängig von der verwendeten Datenaustauschtechnologie (wie in unserem Fall der Blockchain). So ergäbe die Verwendung einheitlicher Keys wie GLN und GDTI auch dann Sinn, wenn sich das Konsortium auf eine zentrale Datenbank geeinigt hätte.

Mehr Details gefällig? Aber gerne!

Einigen Lesern wird dies als Einblick vielleicht schon genügen. Wer jedoch neugierig ist, wie konkret die erwähnten Standards in der Blockchain-Lösung eingesetzt wurden, aus welchen Daten die Blockchain-Transaktionen bestanden und wie sie genutzt werden können, um die Paletten-Konten der beteiligten Tauschpartner zu führen, ist herzlich eingeladen, weiterzulesen.

GS1 Identifikationsstandards

Egal über welchen Kanal Unternehmen Daten untereinander austauschen – z.B. via EDI, EPCIS oder GDSN – es ist stets wesentlich, alle relevanten Geschäftsobjekte konsistent und einheitlich zu identifizieren. Man stelle sich das Chaos vor, wenn sich jeder Tauschpartner mit einem proprietären Schlüssel identifizieren, eine eigene ID für die zu tauschenden Paletten verwenden und dies alles noch in einem eigenen Nachrichtenformat mit unternehmensindividuellen Feldern und Datenformaten speichern würde. Der Mapping- und Integrationsaufwand und die damit einhergehenden Mehrkosten wären enorm.

Zum Glück stehen bereits alle Standards zur Verfügung, um derartige Ineffizienzen erst gar nicht entstehen zu lassen!

Eine zum Ende des Praxistests durchgeführten Umfrage ergab beispielsweise, dass die GLN bereits mehrheitlich (d.h. zu etwa 55 %) seitens der teilnehmenden Partner genutzt wird, um ihre jeweiligen Geschäftspartner zu identifizieren. Die damit verbundenen Synergieeffekte liegen auf der Hand: so können diese Partner die GLN u. a. konsistent in der Stammdatenverwaltung, zur Führung der Paletten-Konten bis hin zum Triggern zugehöriger EDI-Nachrichten (wie z. B. einer Rechnung zum Ausgleich geschuldeter Paletten) verwenden.

Obwohl keiner der an der Umfrage teilnehmenden Unternehmen die Frage nach Verwendung der GLN zur Identifizierung von Geschäftspartnern mit einem ‚Nein‘ beantwortet hat, besteht unter den verbleibenden 45 %, welche hierzu keine Angabe gemacht haben, noch Verbesserungspotenzial. Allerdings befanden sich unter den Rückläufern u.a. auch IT Solution Provider, die selbst in keinen Warenflüssen involviert sind und somit keine Paletten tauschen. Unabhängig davon waren jedoch ausnahmslos alle der am Praxistest teilnehmenden Unternehmen GS1 Lizenznehmer und hätten somit die Möglichkeit, sich in einem digitalisierten Palettentausch-System mittels einer GLN zu identifizieren.

EPCIS – die Grundlage der Blockchain-Transaktionen

Viele werden sich die spannende Frage stellen: Wie sahen eigentlich die Blockchain-Transaktionen aus? Bei den Tauschtransaktionen handelte es sich im Kern um EPCIS-Events. Da ein typischer Palettentausch typischerweise aus dem Empfang von Vollpaletten und der Abgabe von Leerpaletten (bzw. umgekehrt) besteht, wurde dieser jeweils in zwei Blockchain-Transaktionen heruntergebrochen – einem Palettenempfang („arriving“) und einem Palettenabgang („departing“). Virtuelle Mengenausgleiche, d.h. ohne physischem Warenfluss, wurden mit Eigentumsübergangs-Events („accepting“) abgebildet. Die nachfolgende Tabelle gibt einen Überblick über die Dateninhalte der Blockchain-Transaktionen:

Auch die Verteilung von Lokations- und Partnerstammdaten wurde über die Blockchain gewährleistet – alles andere (z.B. eine zentrale Datenbank) wäre unserem Anspruch auf Gewährleistung echter Dezentralität nicht gerecht geworden. Das Design der Stammdaten-Transaktionen basierte auf dem EPCIS-Stammdatendokument (eine von mehreren Möglichkeiten, via EPCIS Stammdaten auszutauschen) und beinhaltete für eine bestimme GLN folgende Daten:

Das Geniale: sowohl für die Tausch- als auch Stammdaten-Transaktionen konnte auf etablierte Standards zurückgegriffen werden, was dem Konsortium bei der technischen Realisierung viel Zeit gespart hat. Namentlich waren zur Spezifikation der Transaktionen folgende Standards hilfreich:

• EPCIS: Datenmodell, Felder, Datenformate

• CBV: Vokabelelemente zur Bestückung der Transaktionen, z.B. Business Steps und Stammdatenattribute

• EPC Tag Data Standard: EPC URI-Format für alle verwendeten Geschäftsobjekte Wie mithilfe dieser Blockchain-Transaktionen nun eine automatisierte sowie auf absolut vertrauenswürdigen Daten basierende Saldenermittlung funktionierte, erläutert der nächste Abschnitt.

Paletten-Konten der Zukunft: digitalisiert, zuverlässig, automatisiert

Tauschpartner führen stets Paletten-Konten, aus welchen jeweils hervorgeht, wie viele Paletten einem anderen Unternehmen geschuldet werden bzw. ein anderes Unternehmen dem eigenen Unternehmen schuldet. Die Logik zur Ermittlung der Salden auf Basis der Blockchain-Transaktionen besteht aus drei Schritten:

Schritt 1: Selektiere alle Transaktionen, in welchen die eigene GLN als Source (z.B. Oetker) und die GLN des jeweiligen Geschäftspartners (z.B. KV Nagel) als Destination spezifiziert ist und summiere die Mengen im quantity-Element. Subtrahiere davon diejenigen Mengen, die durch Error Declaration-Transaktionen im Nachhinein als inkorrekt gekennzeichnet wurden.

Schritt 2: Dito, umgedreht (d.h. Source = GLN KV Nagel, Destination = GLN Oetker)

Schritt 3: Subtrahiere das Ergebnis aus Schritt 2 von dem aus Schritt 1 (d.h. ∑1 - ∑2). Ist der Wert positiv, schuldet der Geschäftspartner (KV Nagel) dem eigenen Unternehmen (Oetker) Paletten. Ist er negativ, verhält es sich in entgegengesetzter Richtung.

Grundsätzlich muss eine Applikation zur sauberen Ermittlung des Saldos bis zum Genesis Block zurückgehen (bei eventuellen Unklarheiten stellt dies eine absolut zuverlässige Art und Weise zur Ermittlung der jeweils geschuldeten Paletten dar). Sofern ein Tauschpartner jedoch eine entsprechende Logik in seinen Business Applikation einsetzt, können zur Vereinfachung Zwischensalden gespeichert werden (bspw. zum Ende eines Abrechnungszyklus), sodass nicht immer bis zum Genesis Block zurückgerechnet werden muss. Hinweis: dies funktioniert auch bei nachträglichen Korrekturen absolut sauber, da auch Error Declaration Events erst danach in der Blockchain persistiert werden.  

Beispiel: 1:1 Tausch

Dieses Szenario ist in der Praxis am häufigsten anzutreffen: ein Partner lädt z.B. volle Paletten bei einem Unternehmen ab und nimmt im Gegenzug Leerpaletten auf. Zum besseren Verständnis zeigt die folgende Grafik zunächst, welche physischen und virtuellen Paletten-Eigentumsübergänge inklusive zweier Korrekturbuchungen zwischen zwei Unternehmen (wir bleiben bei Oetker und Kraftverkehr Nagel, die im Praxistest tatsächlich beteiligt gewesen sind) stattgefunden haben:

Anhand dieses Beispiels würde die Ausführung der drei Schritte wie folgt aussehen:

Schritt 1: Eine Applikation extrahiert die Kerninformationen aus den Blockchain-Transaktionen und lädt sie beispielsweise in eine geeignete Tabelle, die – vereinfacht – wie folgt aussieht:

Die hieraus resultierende Palettenmenge, die Oetker an KV Nagel übergeben hat, ist somit 277 (30+55+45+60+45+15+27). Die 20 Paletten, die am 03.10.2018 verladen wurden, wurden im Nachhinein mittels Transaktion #7 als nicht korrekt deklariert (bspw. aufgrund dessen, dass sich die Paletten als qualitativ minderwertig herausgestellt haben) und dürfen zur Aufsummierung folglich nicht berücksichtigt werden.

Schritt 2: wie Schritt 1, nur in entgegengesetzter Richtung. Die GDTI (in obiger Grafik vereinfacht mit ‚A‘, ‚B‘, … bezeichnet) fungiert hierbei als Klammer eines jeden Tauschvorgangs, der jeweils aus Abladung (Arriving) und Verladung (Departing) von Paletten besteht.

In diesem Fall ist die Palettenmenge 186 (30+40+24+0+50+42). Auch hier „nullt“ die Error Declaration Transaktion (#3) die ursprüngliche Transaktion (#2) aus – zur Berechnung der Summe wird lediglich die in der Korrektur-Transaktion (#4) erfasste Menge berücksichtigt.

Schritt 3: Die Differenz aus Schritt 1 und 2 beträgt 91 (277-186). Folglich würde in diesem Beispiel KV Nagel Oetker 91 Paletten schulden. Hieraus resultierenden folgende Saldenkontostände:

Dieses Prinzip funktioniert auch bei komplexeren Szenarien, z.B. einem Dreier-Tausch unter Einbindung eines Paletten-Pooling-Dienstleisters. Auch das wurde in unserem Projekt durchgespielt und getestet.

Fazit und Ausblick

Dass Standards in Blockchain-Projekten bei der Implementierung spürbar helfen können, hat sich nicht nur konkret in unserem Praxistest gezeigt, sondern spiegelte sich auch im Antwortverhalten im Rahmen der bereits erwähnten Befragung wider. Auf die Frage „Inwiefern würde Ihnen die Berücksichtigung von GS1 Standards (z.B. Idente, Attribute, Datenmodelle, Schnittstellenstandards) die Integration in Ihre Systemlandschaft erleichtern?“ antworteten ganze 77,8 % der Teilnehmer mit ‚viel‘ oder ‚sehr viel‘. Keiner der Teilnehmenden war der Meinung, dass Standards nur ‚wenig‘ bzw. ‚sehr wenig‘ helfen.

Eine weitere wichtige Erkenntnis aus zahlreichen Diskussionen war, dass es weder sinnvoll, notwendig noch effizient ist, Blockchain als Datenaustauschinfrastruktur für alle möglichen Daten zu nutzen – ganz im Gegenteil! Im Falle unseres Projektes hatten wir einen Use Case, in dem der Einsatz der Blockchain-Technologie ein valider Kandidat ist. Gleichzeitig war es für die Praxispartner u.a. nie ein Thema, etablierte Datenaustauschtechnologien wie z.B. elektronische Rechnungen (etwa zum Ausgleich von Paletten-Schulden) über Blockchain abzuwickeln.

Somit zeichnet sich ab, dass Blockchain etablierte Datenaustauschtechnologien ergänzt, jedoch nicht ersetzt. In diesem Sinne wird sich Blockchain voraussichtlich in das bestehende Set an Datenaustausch-Ansätzen einreihen, die in der GS1 Welt bereits existieren: Punkt-zu-Punkt-Datentransfer (z.B. EANCOM), zentrale Datenbanken (z.B. e-Commerce-Plattformen) und föderierte geteilte Datenbanken (z.B. GDSN und GEPIR). Die nachfolgende Grafik illustriert die komplementäre Rolle, die Blockchain in bestehenden IT-Systemlandschaften spielen könnte:

Egal welchen Ansatz man wählt – die Verwendung von global gültigen IDs, Attributen, Datenformaten und Datenmodellen ist von zentraler Bedeutung – unabhängig davon, ob eine Applikation auf Blockchain basiert oder nicht.

GS1 arbeitet kontinuierlich an wichtigen Bausteinen für künftige IT-Systeme. Aktuelles Beispiel ist eine moderne (JSON-LD) Syntax sowie state-of-the-art REST APIs für EPCIS – beides prädestiniert für Blockchain-Anwendungen. Neben diesen technischen Aspekten wird GS1 Germany im Rahmen der Fortsetzung des Blockchain-Projekts gemeinsam mit den Praxispartnern gerne die weitere Ausgestaltung der Governance in Konsortiums-Blockchains moderieren.

Interesse, diese und noch viele weitere Themen in einem engagierten Projektteam auf Augenhöhe mitzugestalten? Melden Sie sich bei uns – spannende Diskussionen, wertvoller Gedankenaustausch und Spaß sind bei uns garantiert!

GS1 Germany

Zurück zur Übersicht