Aus der Praxis: Intralogistikinvestitionen richtig einschätzen und umsetzen

Wer Investitionen in die Intralogistik-IT tätigen will, der benötigt zunächst ein Verständnis für das Gesamtsystem. Dann stellt sich die Frage nach der Lösung: Soll es ein Monolith oder sollen es Microservices sein? Denn der Teufel steckt oft im Detail.

„Hey, alles glänzt, so schön neu.“ Diese Textzeile aus dem Hit „Alles neu“ von Peter Fox mag die Gemütslage der Logistikverantwortlichen ausdrücken,die mit neuen IT-Angeboten in Berührung kommen. Während der Demonstration zeigen sich diese Produkte als resilient und leistungsfähig, bei der Integration in das eigene Unternehmen und dessen IT-Strukturen treten jedoch nicht selten enorme Herausforderungen auf.
Für gelungene Investitionsentscheidungen bedarf es eines tiefen Verständnisses für das Gesamtsystem, denn der Teufel steckt oft im Detail. Eine der zentralen Fragen hier: Stellt ein sogenannter Softwaremonolith die bessere Option dar oder führen kleinteilige Lösungen, also Microservices, zum Ziel? Wie immer ist die Antwort ein klares „Jein“, das wir hier begründen wollen.

Wir werfen einen genaueren Blick auf die Entscheidungsfindung für neue Hardware, um Chancen, Risiken und mögliche Herangehensweisen für die Investition zu beleuchten. Im ersten Schritt müssen die bestehenden Abläufe und vor allem auch die Stakeholder für die Softwarearchitektur identifiziert werden. Ein Beispiel aus unserer Tätigkeit zeigt, was auf jeden Fall zu beachten ist, bevor es zur Entscheidung kommt.

In dieser Fallstudie geht es um die Einführung eines Handscanners im Lager eines international tätigen Automobilzulieferers, in dem das Produkt eines Startups verwendet wird. Die Anbindung an das mobile Datenendgerät (MDE) soll über ein Software Development Kit (SDK) erfolgen, eine Sammlung aus Programmierwerkzeugen und Programmbibliotheken. Dabei ist die Aufmerksamkeit der Verantwortlichen und Stakeholder bereits gefordert, um die erste wichtige Entscheidung zu treffen:

Denn SDKs sind zwar die übliche, aber nicht die einzige Integrationsoption. Der Lösungsansatz des Start-ups liegt darin, das SDK direkt in die Software der MDEs zu implementieren.

Die Vorteile: Eine hohe Zugriffsgeschwindigkeit und bei Integration einer neuen Version stehen alle Features zur Verfügung. Der nicht zu verschweigende Nachteil bei dieser Option:

Das SDK „nimmt die Software beim Absturz mit“. Wenn der Fehler dabei stets an einer bestimmten Stelle im Dialog auftritt, können Prozessschritte über das MDE so lange nicht mehr durchgeführt werden, bis der Fehler behoben ist. Deshalb müssen Entwickler aus dem eigenen Unternehmen oder des MDE-Anbieters einbezogen werden. Sie müssen sich nun mit Codes befassen, die sie nicht selbst geschrieben haben, was wichtige Kapazitäten unter Umständen nicht nur kurzfristig bindet.

Bei Kaufentscheidungen brauchen die Verantwortlichen dringend das Feedback von Experten aus der Software- und Prozessebene, um unterschiedliche Argumente gegeneinander abzuwägen und zu einem tragfähigen Konsens zu kommen. Der Prozessverantwortliche sollte dabei stets schauen, ob Geschwindigkeit oder Sicherheit den Vorrang erhalten soll. Dort, wo Soft- und Hardware aufeinandertreffen, müssen klare Leitplanken für die Interaktion der Systeme gezogen werden. Im dargestellten Fall ist es so, dass Android ähnlich wie ein Großteil der Intralogistik-IT auf Betriebssystemebene über eine Telegramm-Software kommuniziert, an der sich die jeweiligen Anwendungen für den Nachrichtenversand und -empfang anmelden können. Statt die Hardware über ein SDK zu integrieren, kann der Hardwareanbieter also eine eigene Anwendung zur Verfügung stellen, die sich in diesem Telegramm-System anmeldet. Über diese Mittlerinstanz interagiert die besagte Applikation mit der Kommissionieranwendung auf dem MDE.

Fällt die Entscheidung in dieser Form, dann kommuniziert zwar die Kommissioniersoftware nicht mehr direkt mit der Hardware, doch bringt dies bei einem manuellen Prozess ohnehin keine Vorteile. Da das SDK nicht mehr direkt integriert ist, profitiert diese Lösungsart hingegen
von gesteigerter Sicherheit – mit dem zusätzlichen Gewinn, dass im Zweifelsfall die App zur Steuerung der Hardware bei einem Absturz keine weiteren Anwendungen beeinträchtigt. Aufseiten des Hardwareanbieters entsteht so zunächst mehr Aufwand, doch dieser zahlt sich langfristig in der Zusammenarbeit aus. In einem geschlossenen System, in dem Hard- und Software von einem Anbieter genutzt und eine hoch automatisierte Anlage auf hohem Durchsatz gefahren wird, kann es durchaus sinnvoll sein, auf eine zentralisierte Lösung zu setzen. Jedoch geht dies immer mit dem Risiko einher, sich als Unternehmen in den „Walled Garden“, also in eine geschlossene Plattform zu begeben. Flexibilität und Innovationsfähigkeit können dadurch leiden. Microservices sind aber auch nicht immer das Maß aller Dinge. Denn auch mit ihnen können sich Unternehmen beim Wunsch, Prozesse zu optimieren, ein Eigentor schießen. Sind nämlich alle Abläufe voneinander getrennt, verlagern sich die Probleme in die Kommunikation der einzelnen Lösungen untereinander, gibt es so oft keinen gemeinsamen
Nenner mehr. Die Grenzen des jeweiligen Einzugsbereiches werden sozusagen verteidigt und eine Art von „Misstrauen“ im Informationsfluss entsteht. Das führt nicht selten zu sich gegenseitig blockierenden Arbeitsanweisungen oder nicht mehr aufeinander aufbauenden Prozessschritten.

Die beiden wichtigsten Fragen, die sich Entscheider mithilfe der jeweiligen Domänenexperten, also jenen „Herrschern“ der Fachbereiche, stellen sollten, sehen wie folgt aus:

• Was sind die Aufgaben?
• Mit welchen zur Verfügung stehenden Mitteln können sie gelöst werden und wie interagieren diese miteinander?

Je besser eine Aufgabe beschrieben wird, desto schneller kann sie durch die Projektbeteiligten inhaltlich durchdrungen werden. Und dies alles, bevor die erste Zeile Code geschrieben ist!

Schon Albert Einstein sagte: „Das Problem zu erkennen, ist wichtiger als die Lösung zu erkennen, denn die genaue Darstellung des Problems führt zur Lösung.“ Wenn man so vorgeht, dann erwachsen daraus wirksame Investitionsentscheidungen für die Modernisierung beziehungsweise Erweiterung von Warehousing-Kapazitäten.

Dieser Beitrag erschien im Sonderheft Software in der Logistik 2024 des Fachmagazins Logistik Heute und ist als PDF verfügbar.

Zu unseren Projekten
Zu unseren Digitalisierungsthemen
Zurück zur Startseite