Weniger suchen – Mehr finden | Open Source Technologie meistert Kostendruck in der Logistik

Im Endeffekt habt ihr, Ersan, eine Virtual-Warehouse-Lösung geschaffen – ich weiß nicht, ob das dann IoT-Apps sind von eurer INTRANAV-Plattform, die ihr dann aufgebaut habt. Wenn man so ein riesiges Projekt angeht, mit unterschiedlichsten Initiativen, was war euch zu so einem Projektstart wichtig und worauf ist vor allem zu achten, wenn man so etwas angeht?

Ersan

Wie es Johannes auch schon gesagt hat, es ist sehr wichtig, dass wir im Team – damit meine ich nicht nur mich, sondern auch die, die mit dran arbeiten – den tatsächlichen Kundenschmerz verstanden haben, sodass wir alle mehr oder weniger aligned in eine Richtung vorstoßen. Weil das Auswirkungen hat, gerade in Dingen, die vorher noch nie so gemacht wurden. Dass die Architektur passt, und man nicht später herausfindet, jetzt muss alles doch noch mal gedreht werden. Das ist in der Geschwindigkeit, in der wir das gemacht haben, ein No-Go. Daher war es sehr wichtig, dass wir uns intensiv mit Johannes und auch seinem Team in mehreren Workshops unterhalten haben, wo dann zum Beispiel die Themen besprochen wurden: Wie sieht die IT-Architektur aus? Werden unsere Funktionen direkt in das SAP-Zielsystem programmiert oder gibt es eine Zwischenebene – wo sich dann herausgestellt hat, ja die gibt es.

Die Kollegen, unser Counterpart beim Johannes, es hat wirklich wundervoll geklappt, das wir uns da die Schnittstellen überlegt und abgestimmt und es wirklich skalierbar umgesetzt haben. Dabei hat sich herausgestellt, wie am Ende die Zielarchitektur für diesen ersten Piloten, also den ersten Use Case aussehen muss und wie sie denn auch skalierbar aussehen kann und wird. Dabei war es sehr wichtig, zu verstehen, dass wir dort nicht nur in der Cloud agieren und Daten vom SAP herumshiften. Sondern dass wir Hardware on-ground haben, also einen RFID-Reader. Der hat die Herausforderung, dass er die Daten senden muss. Man muss in Betracht ziehen, dass das nicht immer klappen kann.

Ein ganz konkretes Problem: Wir hatten eine WLAN-Brücke aufgebaut – und in so einem Warehouse, wenn entsprechend die Leute nicht aufgeklärt sind, was da gerade vorgeht, wird so ein schwarzes Kästchen aus der Steckdose gezogen, damit man schnell ein Handy laden kann. Auf der anderen Seite bricht da gerade das gesamte System zusammen und das Warehouse erkennt die Kartons nicht mehr. Das sind Kleinigkeiten, die in dem Teststadium aufgefallen sind, die dann notiert werden; und wir erkennen, wenn wir produktiv sind, dann werden wir nichts an eine normale Steckdose hängen, sondern wir stellen sicher, dass die Datenübertragung produktiv einsetzbar ist.

Dann geht es weiter: Wie arbeiten die Leute mit dem System? Dort wird eine externe Containercrew eingesetzt, die die Pakete aus dem Container entlädt und über unser System einscannt. Entsprechend müssen diese Personen darauf geschult werden, auf einmal mit einem IT-System zu arbeiten. Die Themen, dieser kleine Change, der muss richtig und sauber durchgeführt werden. Es muss eine Akzeptanz erzeugt werden. Die UI darf nicht so sein, wie ein Entwicklerkollege sich das vorstellt bei einer App. Sondern es müssen vielleicht ganz andere Element in den Vordergrund gezogen und die Daten visualisiert werden. Deshalb ist es auch wichtig, zu verstehen, welcher Datenkontext ist denn wichtig für die Leute, die mit dem System am Ende arbeiten?

Ich mache es ein bisschen plastisch: Beim Navigationssystem sind wir daran gewöhnt, dass da die Route und ein roter Pfeil ist. Im Gabelstapler-Fall – man kann sich jemanden vorstellen, der noch nie in der Logistik vorher gearbeitet hat, vielleicht braucht ja der Gabelstaplerfahrer eine Art Mini-Navi mit einem Pfeil … aber das ist falsch gedacht. Die Leute kennen ihr Lager so gut, sie brauchen nur die Lagerstellplatznummer ganz groß angezeigt zu bekommen, dann wissen sie schon, wie man optimal da hinfährt. Das Wichtige ist dann die Reihenfolge, die wir dann im Aspekt der Routenoptimierung betrachten. Deswegen brauchen wir die Location-Daten, denn wir müssen ja wissen, wo man steht, damit man optimiert durchfahren kann.

In die komplexere RFID-Schiene, die Kartons haben Barcodes, die werden in China beziehungsweise bei einem Partner im Ausland aufgeklebt. Da ist es wichtig, zu verstehen, wie wird das aufgeklebt? Wie werden die Daten überhaupt erzeugt? All das gilt es dann auch irgendwo in einem gemeinsamen Dokument unterzubringen, das man dann später auch mit den Suppliern bespricht, damit dort das Richtige gemacht wird.

Johannes

Als Ergänzung zu dem Changemanagement: Die Schulung der Lagermitarbeiter im Umgang und im Einsatz solcher Technologien ist ein extrem wichtiger und entscheidender Punkt an dieser Stelle. Oft ist eine gewisse Hemmschwelle gegenüber solchen Technologien vorhanden. Deswegen muss man die Mitarbeiter auch in mehreren Durchläufen an die Hand nehmen und es ihnen erklären. Nur so wird sichergestellt, dass die Technologie nachhaltig akzeptiert wird. Dann ergibt sich auch die Anforderung an einen Logistikmanager in so einem Warehouse. Die verändert sich auch extrem. Plötzlich braucht man neben den Leadership-Skills und den betriebswirtschaftlichen Aspekten auch grundlegende IT Skills. Man muss gewisse Analysefähigkeiten mitbringen, um aus gewonnenen Daten die richtigen Maßnahmen abzuleiten. Generell mit der Implementierung solch einer Technologie ergeben sich extreme Herausforderungen. Das heißt für die Arbeitsplätze in der Zukunft, dass diese komplexer werden. Das ist sehr spannend, das Ganze.

 

Steht und fällt mit den Mitarbeitern am Ende, die, wie du schon sagst, plötzlich datenbasiert Entscheidungen treffen, was natürlich neue Anforderungen mit sich bringt.  Wenn wir schon beim Erklären dieses Systems sind, man muss viel darüber sprechen … Ihr habt diese IT-Architektur aufgenommen und auch die Schnittstellen genau angeschaut. Ich würde jetzt gerne verstehen, wie das Ganze von der Datenaufnahme über die Verarbeitung bis hin zur Analyse funktioniert. Kannst du diese IT Architektur grob beschreiben, um anschließend tiefer darauf einzugehen?

Ersan

Wir sind gestartet als ein Unternehmen, das sich ausschließlich mit Industriekunden beschäftigt. Der Industriekunde vor sieben, acht Jahren sagte, Cloud, niemals. Inzwischen ein Riese wie Siemens Energy, der zieht seine Cloudstrategie durch. Der hat die Mehrwerte und Vorteile erkannt und setzt diese entsprechend um. Kudos an Siemens Energy, aber so funktioniert der Mittelstand nicht immer. Deswegen ist es sehr wichtig, eine Lösung zu präsentieren. Manche nennen das Hybrid Cloud. Man hat also irgendwo eine Recheneinheit vor Ort, die die Daten speichert und verarbeitet. Vielleicht werden da nur gewisse Ergebnisse nach oben geliefert, in die Cloud. Hier im Fall von Johannes ist es so, dass die Firma TB International eine sehr gute Cloudstrategie hat. Entsprechend ist das SAP-System in der Cloud. Wir haben trotzdem noch die Herausforderung, dass wir Echtzeitdaten benötigen im Warehouse und wir brauchen eine gewisse Ausfallsicherheit. Das heißt, was passiert, wenn das Internet ausfällt? Das ist ein Desaster-Szenario, aber inzwischen gleichzusetzen mit, was ist, wenn der Strom ausfällt? Da ist es wichtig, dass dadurch, dass wir eine gewisse Latenz haben oder vermeiden wollen, wir vor Ort eine Edge Computing Unit haben, die sich um das Sammeln dieser IoT-Daten kümmert. Das sind dann zum Beispiel die Location-Daten, also die Ultra-wide-band-Positionierdaten des Gabelstaplers. Da ist ein kleines Gerät drauf, welches uns sehr exakt vermittelt, wo sich dieser Gabelstapler befindet. Da macht es einen Unterschied, ob wir das in zwei Sekunden erhalten oder in drei Minuten, denn in drei Minuten kann er ganz woanders sein. Diese Edge Unit sendet über einen Message-BUS, das ist MQTT, die Daten in unsere Cloud-Gegenstelle. Das ist ein sicherer Kanal. Dort sind über eine REST API die Schnittstellen an unsere API, die zum SAP führt. So haben wir diesen Hybrid-Cloud-basierten Ansatz verfolgt. Diese gesamte Software-Architektur ist von uns dockerisiert, das ist der Vorteil. Wenn jemand vor dieser Herausforderung steht, ein IoT-System in diesem Maße zu implementieren, kann man mit Dockern wunderschön eine Simulierumgebung bei sich im Büro schaffen, die den Alltag im Testing vereinfacht. Wir können sozusagen ein digitales Abbild von diesem Lager erzeugen, testen das, und können entsprechend schauen, dass wir das deployen. Was jetzt noch eine kleine Besonderheit ist, diese Architektur: Da haben wir ein bisschen die Big-Data-Kollegen angeschaut, die haben noch ein sogenanntes Apache-Kafka-Cluster. Warum wir das brauchen, ist aus dem Grund, weil tatsächlich der Gabelstapler und die anderen Teilnehmer so viele Daten erzeugen. – Wenn Johannes eine Heatmap erzeugen möchte, welche die Verkehrssituation in dem Warehouse abbilden soll … das ist so eine Datenflut, dass das ein normales System in einer normalen Zeit nicht mehr abbilden kann, deswegen ist dieser Backbone basierend auf der Big-Data-Architektur schon implementiert, und dadurch sind solche Heatmaps relativ schnell, in Sekunden erzeugbar.

 

Es geht um bestimmte Daten, die aufgenommen werden; um RFID-Reader, also auch Tags, die an den unterschiedlichen Hardware Devices beteiligt sind. Das kann ein Gabelstaplerfahrer oder ein Produkt sein. Wie funktioniert die Datenaufnahme vom RFID oder beziehungsweise den Containerdaten?

Ersan

Es ist unser Steckenpferd, verschiedenste Datenquellen in dem Themengebiet aufzunehmen, sei es RFID, Bluetooth, Wi-Fi oder GPS. Was wir tun, ist, wir haben eine Standartsituationsebene geschaffen, wo wir diese Daten einsenden. Jetzt fangen wir mal mit dem Container an. Der Container hat zum Beispiel einen GPS-Tracker, der schickt die Daten an unsere Integration für diese Container-GPS-Daten und speichert diese in einem JSON-Format bei uns auf der Plattform, sodass man das in der Datenbank zur Verfügung gestellt bekommt.  Beim RFID ist es so, dass die RFID-Labels eine ID enthalten, die uns die Kartoninformationen gibt, die wir dann im SAP auch abfragen können. Dann erhalten wir die Daten, was drin ist. Ob es hundert Stück oder zehn Stück sind. Das erfasst wiederum ein RFID-Reader von einem namenhaften Hersteller. Diese Daten werden über einem industriellen BUS, in dem Fall Industrial Ethernet, an ein Gateway gesendet. Dieses Gateway schickt dann wiederum an unsere INTRANAV-IO-Plattformen diese Daten, genau wie der GPS-Container an ein Integrationsmodul, und wir erhalten hinten wieder standardisierte Datenformate.  Warum machen wir das? Weil wir eigentlich in der Zukunft wollen, dass der ambitionierte Kunde oder Partner das selbst machen kann. Selbst Applikationen draufbauen kann. Eigentlich weil wir selbst immer so arbeiten, dass wir App-Entwickler für unsere eigene Plattform sind, sodass ein Partner ebenfalls Apps für unsere Plattform entwickeln kann. Deshalb ist es wichtig, dass man Standartschnittstellen hat. Beim Ultra-wide-band genau das gleiche: Wir erhalten die Daten von dem Gabelstapler über ein Ultra-wide-band-System, kriegen sie dann wieder standardisiert an unsere Schnittstelle, wo wir dann entsprechend die Daten aggregieren können in unseren Apps.

 

Wie schafft ihr es denn diese Daten in Echtzeit zu übertragen?

Ersan

Wir haben einmal darauf gesetzt, dass wir Protokolle verwenden, die einen geringen Overhead haben. Man muss sich das so vorstellen, wenn ich jetzt mit der Mutter telefoniere und ich habe ein Protokoll, dass ein hohen Overhead hat, dann würde ich sehr förmlich sprechen, »Guten Tag Frau Mutter, wie geht es Ihnen? Darf ich heute Abend zum Essen kommen?« Oder eines mit geringem Overhead, »Mama, was gibt’s zu essen, ich bin um 18 Uhr da?«. Das Gleiche gibt es auch in der Technik. Wenn man Letzteres verwendet, hat man weniger Sprechzeit, dafür längere Latenzen. Entsprechend haben wir das auch umgesetzt in der Plattform. Das heißt konkret, es gibt von Google ein protobuf-basiertes Protokoll, das kann man googeln. Das hat einen sehr geringen Overhead, und dadurch können wir diese Echtzeiten von Millisekunden schaffen.

 

Du hast unterschiedlichste Schnittstellen angesprochen, und auch in der Architektur kommen verschiedene Datenquellen zusammen. Da kann man fast schon von einem Datenchaos sprechen, wo ganz unterschiedliche Systeme, die schon vorhanden sind, irgendwo integrierbar gemacht werden müssen.  Der nächste Schritt ist, diese Daten verfügbar zu machen in einzelnen Systemen. Wie könnt ihr diese Daten strukturiert auch in andere Systeme integrierbar machen?

Ersan

Das ist ein sehr wichtiger Punkt, weil wir schauen müssen, dass diese Daten, die wir aufgreifen, entsprechend den Prioritäten verarbeitet werden. Zum Beispiel Verbuchungen, das heißt, der Gabelstapler lädt gerade etwas in ein Lagerregal ein, und es ist sehr wichtig für Johannes und TB International, sofort zu wissen, dass diese Ware in dem Regal ist, weil das buchhalterisch dann sofort im Shop zur Verfügung steht. 

Johannes

Kurz nochmal aus der Praxis, wir haben dahinter über eine Schnittstelle ein Data-Mining-Tool geschaltet. Dort laufen die Daten wirklich aktuell rein und dann werden sie über ein Power-BI-Dashboard visualisiert und bei uns im Leitstand, in der Logistik angezeigt. 

Ersan

Daten, die zum Beispiel dort visualisiert werden, zeigen den Stand des Lagers, des Auftragsverhaltens. Deswegen ist es wichtig, dass wir schnell Daten an diese Schnittstellen liefern können. Es gibt auch Daten, die sind nicht so wichtig. Entsprechend haben wir ein Datenmanagement aufgebaut, das diese Daten nach diesen Kriterien in die Datenbank und auf der API zur Verfügung stellt. Es gibt auch Kunden, die haben Gabelstapler Safety als Use Case. Das heißt, wenn zwei Gabelstapler sich zu nahe kommen, muss ein Alarm stattfinden. Das hat natürlich ganz andere Anforderungen, aber auch da ist die Priorität sehr hoch und entsprechend werden diese Daten, die verarbeitet werden, gestaffelt und auf der API zur Verfügung gestellt. Die Daten speichern wir auf der Festplatte. Wenn im nächsten Schritt ein Data Lake angekoppelt werden soll, dann sind die Daten schon so aufbereitet, dass diese in ein Data Lake einfließen können. Das ist ein Trend, der sich immer mehr abzeichnet. Bei TB International ist das auch schon in der Tat umgesetzt.

 

Johannes, du hast vorhin auch die Heatmaps angesprochen, rund um die Fahrer. Ihr wollt jetzt eine Live-Verortung dieser Daten machen. Ersan, wie funktioniert diese Datenanalyse? Also ich muss irgendwie wissen, wo befinden sich die Fahrer, wo fahren sie hin, wo gibt es die Potenziale dann auch? Wie macht ihr das?

Ersan

Wir haben ein sogenanntes RTLS-System. Das steht für Real-time Locating System. Und wir haben zwei Produkte im Portfolio, einmal einen Laserscanner, ein sogenanntes Lidar, wie es auch beim autonomen Fahren verwendet wird, mit dem sich der Gabelstapler verorten kann. Er weiß dann immer ganz exakt, wo er ist. Nachteil an der Technologie ist, dass sie sehr teuer ist. Für den Use Case bei TB International haben wir uns bewusst für ein Ultra-wide-band-basiertes System entschieden. Das heißt, ich habe wie beim WLAN Accesspoints, und je nach Signallaufzeit … der Stapler sendet etwas aus, ähnlich wie beim GPS empfangen dann mehrere Teilnehmer das Signal und können dann auf Basis der Zeit, die dieses Signal gebraucht hat, um empfangen zu werden, die Position ausfindig machen. Trilateration. Diese Daten brauchen wir, um Use Cases abzubilden, wo Standortinformationen in einem Warehouse wichtig sind. Warum kann man kein GPS benutzen beim Gabelstapler? Weil das Metalldach das Signal abschirmt, darum gibt es kein GPS in der Halle, sondern man braucht diese Indoor-GPS-Systeme. Die Heatmap reflektiert die Standzeit und Ort anhand von Farben. Wenn irgendwo auf dieser Heatmap – man kennt es aus dem Fußball – etwas grün markiert ist, dann heißt es, okay, an diesem Ort war die Handlung nur eine kurze Zeit, und sobald es gelb oder rot wird, da stand jetzt der Gabelstapler ziemlich lange. Wann ist das relevant? Wenn zum Beispiel an Kreuzungen sehr oft Gabelstapler stehenbleiben: das heißt, irgendetwas stimmt mit dem Verkehr nicht. Oder wenn man AGVs einführt, also automatische Fahrzeuge ohne Fahrer, ist es auch relevant für unsere Kunden, zu wissen, wie sich denn das AGV verhält. Denn immer mehr wird es so kommen, dass AGVs Vorfahrt haben und die Gabelstapler andere Verkehrsregeln haben. Deswegen, man möchte wissen, wie ist der Materialfluss, wie fließt mein Material, wie lange steht das? Diese Heatmaps sind eine der relevanten Datengeber.  Was kann man noch Schönes machen? Man kann Spaghettidiagramme machen. Damals in meinem Praktikum bei einem Beratungsunternehmen musste ich immer eine Stoppuhr in der Hand halten und schauen, wo waren denn die Teilnehmer? Dann musste ich selber diese Linien zeichnen – unser System wirft das praktisch per Button aus.

 

Johannes, wie funktioniert das bei euch in der Praxis? Was ist euch da wichtig

Johannes

Das funktioniert in der Praxis wunderbar. Wir haben tatsächlich über die Power-BI-Anzeige oder direkt Zugang auf die INTRANAV-Plattform und können per Livedaten die Fahrwege analysieren und sehen, an welcher Stelle gibt es Verschwendung? Dann kann der Logistikmanager direkt Maßnahmen ergreifen, um die Verschwendung zu eliminieren und den Prozess schlanker zu gestalten.