6.12.2018
Blockchain hat das Potential ein Ökosystem auf Prozessebene – hier für den Tauschprozess von Mehrweg-Ladungsträgern – zu bilden. Der größte Vorteil der Technologie besteht darin, Daten vertrauensvoll in einem Netzwerk aus unabhängigen Parteien teilen zu können, ohne dass ein einzelner Teilnehmer (vgl. Intermediär) volle Datenhoheit (Einsicht, Manipulation) besitzt. Dies bildet die Basis zur effizienten Digitalisierung von komplexen und sensitiven Prozessen.
Weiterhin wird durch das Schaffen eines geteilten, konsistenten globalen Prozess-Zustandes die Kommunikation und Konsens-Findung im Problemfall deutlich vereinfacht. Dies schafft Vertrauen und regt im Idealfall zu regelkonformem Handeln an. Ein Projektziel ist es außerdem zu zeigen, dass selektives Teilen von Daten weitere Optimierungspotentiale, welche konkret im Nachgang beleuchtet werden können, haben kann.
Die Blockchain-Technologie
Aktuell gibt es eine Vielzahl von Blockchain-Technologien, die für das Enterprise-Umfeld geeignet sind (Private Permissioned Blockchain, eine zugriffs- und zutrittsbeschränkte Form einer Blockchain), sich jedoch in Komplexität und Funktionalitäten deutlich unterscheiden. Beispiele sind:
Grundsätzlich sollte die verwendete Blockchain-Technologie die Erfordernisse aus Anwendungssicht reflektieren. Für dieses Projekt haben wir uns daher bewusst für die einfachste Technologie entschieden, mit deren Hilfe sich das Palettenschein-Szenario realisieren lässt - MultiChain. MultiChain ist direkt aus der Bitcoin-Blockchain abgeleitet, ohne jedoch deren Nachteile (wie bspw. geringen Durchsatz und hohen Stromverbrauch) zu haben. Außerdem lassen sich so die originalen Blockchain-Konzepte leicht nachvollziehen. Ein heterogenes MultiChain-Netzwerk ist so aufgebaut, dass das Konzept der Dezentralität ohne spezielle IT-Kenntnisse und ohne hohen Ressourcen-Einsatz untersucht werden kann. Alle anderen Blockchain-Technologien sind deutlich komplexer und aufwändiger in der Handhabung. Natürlich hat die Einfachheit von MultiChain auch einen Preis: Es kann beispielsweise kein eigener Programmcode (vgl. Smart Contracts) auf der Blockchain ausgeführt werden. Des Weiteren ist die Einschränkung der Datensichtbarkeit nicht vorgesehen und damit komplex in der Implementierung. Mehr dazu im Blog-Beitrag zu den technologischen Erwägungen für den weiterführenden Einsatz.
Die Projektteilnehmer hatten über verschieden Kanäle die Möglichkeit aktiv oder passiv am Blockchain-Netzwerk teilzunehmen:
• Blockchain-Kernnetz in der SAP Cloud Platform: GS1, PwC und SAP haben jeweils einen MultiChain-Knoten auf der SAP Cloud Platform Infrastruktur betrieben. Diese Knoten bilden ein hochverfügbares Kernnetz, welches sicherstellt, dass immer Blockchain-Knoten zur Validierung von Transaktionen und Erzeugung neuer Blöcke (Mining) vorhanden sind
• Externe Blockchain-Knoten: Da es gegen das Blockchain-Grundprinzip der Dezentralität verstößt, alle Knoten in einer einzigen Cloud zu betreiben, haben sich die meisten Projektteilnehmer einen eigenen MultiChain-Knoten außerhalb der administrativen Hoheit von SAP eingerichtet. Diese Knoten liefen teils auf einer anderen Cloud (z.B. Amazon Web Services, Microsoft Azure) oder aber im eigenen Rechenzentrum der jeweiligen Teilnehmer
• Paletten-Portal und mobile Datenerfassung: Für alle Fahrer der Speditionen und Lagerarbeiter der Versender und Händler stand eine mobile Web-Anwendung für Smartphone oder Tablet zur Verfügung, die über die SAP Cloud Zugriff auf das Blockchain-Netzwerk erhält. Das „Paletten-Portal“ erlaubte die Interaktion mit der Paletten-Anwendung für Sachbearbeiter (so genannte Business-Sicht)
Die Entwicklungsphase
Während der Entwicklungsphase lag der Schwerpunkt zunächst auf der Bedarfsanalyse. Dabei bot es sich an, die späteren Nutzer in den Vordergrund zu stellen (User-Centric Design) und Prozess sowie Abläufe daraus abzuleiten. Nach einem ersten Workshop mit einer großen Zahl der späteren Pilot-Teilnehmer gab es neben einer detaillierten Prozessbeschreibung bereits die ersten Ansätze, wie eine spätere Anwendung funktional aussehen müsste.
Diese grobe Beschreibung diente als Basis des Designs der schlussendlichen Anwendung. Design ist hier aber mehrdeutig, denn nicht nur Screens müssen gestaltet werden, sondern auch Abläufe in einer Anwendung. Folgende Aufgaben ergaben sich daraus:
• Erstellung der Mock-Ups / High-Fidelity Design Entwürfe
• Datenmodell-Design mit Hilfe der GS1 Standards
• Anwendungs-Design der Blockchain-Anwendung
Die finalen Entwürfe und Gedanken zur Anwendung
Auch während der Entwicklungsphase, eigentlich weit nachdem wir uns über die Benutzer-Bedürfnisse Gedanken machten, kamen noch einige interessante Ideen auf. So wurde beispielsweise die Schnellidentifikation via GS1-QR-Code erst während des Entwicklungsprozesses getestet und mit den Ansprechpartnern der Unternehmen validiert. Die finale Version der High-Fidelity Designs kam dann der schlussendlich im Praxistest eingesetzten Anwendung schon sehr nahe.
Datenmodell-Design
Das Datenmodell sollte sich - auch auf Wunsch der Projektteilnehmer - eng am GS1-Standard EPCIS orientieren. Die Transaktionen selbst stellten hier auch gar kein Problem dar, die Korrekturen oder der Sonderfall eines Tausches über Palletten-Dienstleister waren da schon kniffliger. In langen Gesprächen und unter rauchenden Köpfen ist es uns aber schließlich gelungen, Standard und Blockchain zusammenzubringen. Mehr zu den verwendeten Standards findet sich im Blog zu den genutzten GS1 Standards.
Anwendungs-Design
Eine Blockchain-basierte Anwendung ist grundsätzlich nicht besonders in Architektur oder Design. Ein paar Aspekte gab es allerdings auch hier zu beachten:
• Nutzen von MultiChain Streams: Wir haben uns aufgrund der Durchsatz-Optimierung für den Einsatz von MultiChain Streams entschieden. So existiert zwischen jedem Tauschpaar quasi eine eigene „Tabelle” oder „virtuelle Blockchain”, sodass man also nicht alle Transaktionen global in eine und für Blockchain übliche Reihenfolge bringen muss.
• Nutzen eines separaten Streams für vorgeschlagene Transaktionen: Transaktionsvorschläge sollten selbst noch nicht in der eigentlichen Blockchain, also dem jeweiligen Stream, persistiert werden. Daher haben wir uns für den dezentralen Austausch der Vorschläge auf die Nutzung eines speziellen „Proposal” Streams geeinigt. Alternativ könnte man jede andere Art der Kommunikation, beispielsweise eine Message Queue zwischen allen Teilnehmern, verwenden. Dies würde in unserem Fall aber nur unnötig die Komplexität erhöhen.
• Multi-Signature Transaktionen: Um den Konsens über den Inhalt eines Tausches zwischen den Partnern abzubilden entschieden wir uns für sogenannte Multi-Signature Transaktionen. Das heißt, dass beide Tauschpartner mit ihrem privaten Schlüssel unterschreiben müssen, bevor die Transaktion vollständig ist.
Auswertung der Usability der Pilot-Anwendung
Ein integraler Bestandteil für die Erprobung der Blockchain-Technologie ist Nutzeroberfläche der Palettentausch-Anwendung. Die Bedienbarkeit des Prototypens wurde durch einen Usability Test vor der Pilotphase überprüft und auf Basis des Feedbacks verbessert. So konnte sichergestellt werden, dass Daten und Transaktionen gespeichert werden und Fehlbedienungen unzureichende oder keine Daten entstehen ließen. Im Usability-Test haben wir herausgefunden, dass beispielsweise die Lesbarkeit der Texte für ältere Nutzer kritisch ist, da die Schriftgröße zu klein gewählt wurde. Oder dass viele Speditionen international arbeiten – und demnach weitere Sprachen angeboten werden müssen, um die Bedienung allen Nutzergruppen überhaupt zu ermöglichen. So ging der verbesserte Entwurf in die Pilotphase über und wurde im Alltag parallel zum Papier überprüft.
„Einfach im Handling, teilweise langsam beim Speichern“ Projektmanager Logistik, Dr. August Oetker Nahrungsmittel KG
Die Wahrnehmung der Schnelligkeit der Anwendung wurde ambivalent bewertet. Die meisten Nutzer sind das erste Mal in Berührung mit Blockchain-Technologie gekommen. Bei unserem Piloten wurde beim Speichern auf der Blockchain verständlicherweise mit dem bekannten WWW verglichen, wo Reaktionszeiten im unteren zweistelligen Millisekunden-Bereich normal sind. Da es teilweise etwas dauerte bis die vorgeschlagene Transaktion beim Tauschpartner erschien, war die gefühlte Schnelligkeit beim Tausch langsamer als gewohnt. Dennoch wurde die Echtzeitabwicklung der Transaktion, die Nachvollziehbarkeit der Informationen und die Transparenz beim Tauschprozess als sehr gewinnbringend empfunden. Besonders in nachgelagerten Prozessen sehen die Projektteilnehmer große Optimierungspotenziale.
Auf Basis des ersten Usability-Tests wurde nach der Alltags-Verprobung der Anwendung an alle teilnehmenden Unternehmen der Pilot-Phase eine Befragung mit folgenden Ergebnissen gesendet:
Pro
• enorme Vereinfachung der Palettentauschabwicklung direkt bei der Entladung
• alle weiteren Prozesse, die mit den Palettenscheinen verbunden sind (manuelle Eingabe der Scheine in Computer, Buchung in ERP-Systemen, Führen und Verwalten von Palettenkonten, etc.) können entfallen
• Scanbarkeit der Tauschpartner, um direkt die Transaktion aufzurufen
• Kein Papier
• weniger Diskussionen über die Qualität der Paletten, da diese mit der Transaktion bereits final bestätigt wird
• weniger Fehler bei der Dokumentation (z.B. handschriftlicher Vermerk Anzahl Paletten nicht lesbar)
• Übersicht über sämtliche Tauschprozesse inklusive schadhafter Paletten
Wunschliste
• Ein Datum und Zeitpunkt der Transaktionen in der App
• Sobald in einer LKW-Lieferung viele Teil-Lieferungen zusammengefasst werden müssen viele Informationen von Hand zur Tauschtransaktion hinzugefügt werden; dabei wurde deutlich wie wichtig die Integration in bestehende Systeme ist, um Schlüsselinformationen direkt verknüpfen zu können
• Ein Foto von einer beschädigten Palette aufnehmen und der Lieferung zuordnen können
• Arbeitsgeschwindigkeit erhöhen
• Favoriten, die man schon im Vorfeld aufrufen kann
In der Auswertung wurde neben Feedback für die Funktionalität besonders die „hübsche und intuitive Darstellung“ der Anwendung erwähnt.
Aufbau des Netzwerkes und Onboarding
Der Aufbau des Kernnetzes war der eigentliche Startschuss für den Test. Über die via SAP Cloud Platform zur Verfügung gestellten Dienste wurde dieses schnell aufgebaut. Nun ging es daran, die anderen Projektteilnehmer anzuschließen.
Sowohl subjektiv als auch objektiv (über die durchgeführte Befragung) kann man sagen, dass die Installation und Einbindung der MultiChain Knoten sehr problemlos lief. Nach der eigentlichen Installation erfolgt hierbei die Initiierung der Verbindung mit dem bestehenden Teil des Netzwerkes. Dafür führt der Administrator des jeweiligen Knotens einen Befehl auf der Kommandozeile aus - dieser muss den Namen der (Block-)Chain sowie die physische Adresse (IP Adresse) eines bereits laufenden Knotens kennen. Danach wird bei nicht-öffentlichen Netzwerken die eigene Adresse (Wallet) des Knotens ausgegeben. Sobald diese wiederum von der anderen Seite freigegeben (Whitelist) wird, steht die Verbindung!
Statistiken zum Testlauf
Im Testlauf selbst konnten wir die Blockchain nicht an die Leistungsgrenzen bringen - dafür gab es einfach „zu wenige” Transaktionen. Trotzdem ist es spannend, auf die Ergebnisse zu schauen.
Insgesamt haben wir in den zwei Testwochen über 590 reale Tauschvorgänge zwischen 19 Tauschpartnern abgebildet. Jeden Tag haben Fahrer, Logistiker und Mitarbeiter im Backoffice über 50 neue Vorgänge erfasst. Die Tauschpartner hatten während des Pilot-Betriebs eine relativ gleichmäßige Transaktionsverteilung, wobei die Logistik-Teilnehmer hier eine leichte Mehrheit darstellen.
Kleinere Probleme im Ablauf wie fehlerhafte Logins, Darstellungsfehler oder aber Probleme bei der Kommunikation mit der Blockchain konnten behoben oder durch andere Lösungen umgangen werden.
Die angesprochenen 590 Transaktionen sind zeitlich sehr gleichmäßig verteilt. Man erkennt eine Abnahme der Aktivitäten am Wochenende, sowie täglich zyklisch wiederkehrende Anstiege. Beides ist vor allem mit dem begrenzten Testrahmen zwischen 19 Testpartnern zu erklären.
Die CPU einer MultiChain (Small Plan) Instanz auf der SAP Cloud Platform war konstant ca. 40% belastet - ein sehr anständiger Wert, da auch während des Lasttestes (s.u.) keine Lastspitzen aufgetreten sind. Der Arbeitsspeicher war sehr ausgewogen mit 30% ausgelastet und ist somit ebenfalls ein reservierter Wert der MultiChain Instanz, da dieser nicht nutzungsabhängig zu schwanken scheint. Während der gesamten Testphase waren mindestens 11, maximal 13 Knoten im Netzwerk verbunden.
Bezüglich der Latenz beim Schreiben und Lesen in und aus der Blockchain schlug uns oft die größte Skepsis entgegen, da sich diese in öffentlichen Blockchains einen gewissen Ruf erworben hat. In unserem Fall teilt sich die Betrachtung auf nach Vorschlag und Bestätigung. Für Transaktionsvorschläge lag die Wartezeit hier konstant bei ca. 700ms (0,7s), während die Bestätigung ca. 1,7s Sekunden benötigte. Dies liegt vor Allem an der Implementierung unserer Lösung, die zur Bestätigung mehrfache Schreiboperationen in verschiedenen Streams notwendig macht. Es kam global zu einer Fehlerrate von 0,2% - Fälle, in denen das MultiChain Netzwerk beispielsweise nicht schnell genug reagiert hat.
Ein weiterer wichtiger Punkt ist der verbrauchte Speicherplatz. Eine Transaktion (ein Tauschvorgang) nimmt insgesamt ca. 6,4Kb Speicher auf der global replizierten MultiChain ein, bei den 543 Tauschvorgängen im Praxistest fielen dabei insgesamt ca. 20MB an Daten an. Die Differenz entsteht durch Indizes, flüchtige Daten und Caches.
Der Belastungstest
Da wir, wie oben angesprochen, das Blockchain-Netzwerk während des realen Tests nicht annähernd an die Leistungsgrenzen bringen konnten, entschieden wir uns im Nachgang für einen Belastungstest unseres Blockchain-Netzwerkes. Dieser wurde mit steigenden Transaktionszahlen bis hin zu einem Tauschvorgang pro Sekunde, durchgeführt. Die Ergebnisse sind auch hier durchaus positiv!
Wie oben angesprochen sind CPU-Auslastung, Speicherverbrauch und Latenzen auch im Lasttest nicht angestiegen und somit ein sehr gutes Feedback für die eingesetzte Technologie. Der Test selbst lief für 24h mit einer durchschnittlichen Rate von 1 Transaktion / Sekunde. Insgesamt wurden so116.665 Tauschvorgänge simuliert. Während des Tests wurden ca. 700MB Daten generiert. Die Fehlerrate blieb auch bei einer solch hohen Belastung konstant bei ca. 0,2% der Transaktionen.
Fazit
Ob im eigentlichen Praxistest oder im Lasttest - das technologische Fazit des Projektes fällt überaus positiv aus. Die unmittelbar im Fokus stehenden Technologien wurden erfolgreich erprobt, das Blockchain-Netzwerk schnell und unkompliziert aufgebaut und genutzt. Das erklärt auch, warum sich fast alle Teilnehmer für einen eigenen Knoten, im eigenen Rechenzentrum oder der Cloud, ausgesprochen haben. Ein tolles Ergebnis, dass die Machbarkeit von Dezentralität unterstreicht, aber auch für die Wahl von MultiChain als Blockchain-Technologie spricht. Kein Teilnehmer musste während des Tests Probleme mit der Blockchain lösen oder den eigenen Knoten neu starten.
“Die Idee hinter der Applikation, hat – flächendeckend eingeführt – das Potenzial einen überholten, umständlichen und ineffizienten Prozess erheblich zu optimieren. Die App erfüllt die Anforderungen dafür. Wichtig ist eine möglichst einfache Implementierung in bestehende Systeme, um breite Akzeptanz zu erreichen.“ Speditionsleiter, DHL Freight GmbH Hamburg
Die meisten Teilnehmer (8/11) bestätigten außerdem, dass sie gern mit der Pilot-Lösung gearbeitet haben und diese auch zukünftig weiter nutzen würden. Der Grund hierfür ist wohl, dass wir zeigen konnten, dass Digitalisierung nicht immer mit Kontrollverlust und hohen Nutzerbarrieren zusammen hängen muss. Durch ein strikt nutzer-zentriertes Design im initialen Definitions-Prozess, zwischenzeitliche Nutzer-Tests und Flexibilität bei der Ausgestaltung des Projekt-Rahmens konnte dieses tolle Ergebnis erzielt werden.
Etwas differenzierter fällt das Fazit jedoch beim Blick auf Blockchain als Technologie und in der aktuellen Umsetzung aus. So sprechen sich die meisten Teilnehmer final für nicht-vollständige Transparenz der Tausch-Transaktionen aus - definitiv ein Aspekt der in den Überlegungen für einen weiterführenden Einsatz beachtet werden muss. Die Nutzung des GS1 Standards hingegen bekam viel positive Resonanz, gerade im Hinblick auf die Einbindung eines möglichen Palettentausch-Systems in die eigene Systemlandschaft.
Die Projektteilnehmer sehen großen Mehrwert in der Digitalisierung des Prozesses und das größte Potenzial wird vor allem nach dem eigentlichen Palettentausch gesehen. Nun bleibt abzuwarten, wie aus dem Projekt ein reales Konsortium werden könnte - vielleicht gibt es das größte Potenzial ja auch nach dem Pilotprojekt?
Kommentare
Keine Kommentare