Case Study – flaschenpost SE

Prozesskopplung
optimiert die Warenbewegungen

In einem Warenlager geht es manchmal zu wie im Taubenschlag: rein, raus, kreuz und quer – von morgens bis abends. Doch während im Taubenschlag nur wichtig ist, dass am Ende des Tages genauso viele Vögel da sind wie kurz nach dem Wachwerden, wird im Warenlager der flaschenpost SE jede Bewegung exakt dokumentiert.

Case Study – flaschenpost SE

Ereignisbasierte Prozesskopplung optimiert die Warenbewegung

In einem Warenlager geht es manchmal zu wie im Taubenschlag: rein, raus, kreuz und quer – von morgens bis abends. Doch während im Taubenschlag nur wichtig ist, dass am Ende des Tages genauso viele Vögel da sind wie kurz nach dem Wachwerden, wird im Warenlager jede Bewegung exakt dokumentiert. 

Welches Produkt wird angeliefert? Wo genau befindet es sich im Lager? Wohin wird es verschoben? Wann und an wen wird es ausgeliefert? Das klingt kompliziert, aber ist unverzichtbar für ein Unternehmen wie den Lieferservice flaschenpost SE, der mit haushoher Verlässlichkeit die Wünsche seiner Kunden:innen erfüllen will. Das Geschäftsmodell funktioniert auch deshalb so gut, weil alle angebotenen Produkte jederzeit erhältlich sind. „Nicht auf Lager“ ist für einen Lieferservice keine Option, wenn die Kundenbindung von langfristiger Dauer sein soll. Mit ihrem Versprechen, binnen 120 Minuten ab Bestellung zu liefern, hat flaschenpost SE den Anspruch an die eigene Lagerhaltung noch drastisch erhöht. Waren müssen nicht nur auf den Tag genau zur Verfügung stehen, sondern exakt auf die Stunde. Es reicht nicht, wenn erst am Nachmittag geliefert wird, was am Morgen bestellt wurde. Fehler bei der Bestandsaufnahme kann sich flaschenpost SE nicht leisten. 

Die Anzahl der Anfragen ist stark gewachsen

Doch das exponentielle Wachstum des Unternehmens, das binnen weniger Jahre wegen der starken Nachfrage Dutzende Lager in ganz Deutschland aufgebaut hat, stellte die Logistik zunehmend vor Herausforderungen. Die im Haus entwickelte Software bildete zwar eine solide Grundlage für die Anfänge der Kommissionierung, also die Bereitstellung der Ware für ihre Auslieferungen. Doch nach einer Weile stieß das System zwangsläufig an seine Grenzen. Einerseits war die Datenbank durch die ständig wachsende Zahl an Bewegungen, die dokumentiert werden mussten, am Ende so belastet, dass ihr weiterer Ausbau schlicht unmöglich war. Auch weil die einzelnen Prozesselemente in der monolithischen Software nach dem Polling-Prinzip in schneller Abfolge ständige Abfragen an die Datenbank richteten, ob sie einen Auftrag zu erledigen haben. Man stelle sich vor, ein:e Abteilungsleiter:in sitzt im Büro und im Minutentakt stecken Mitarbeiter:innen den Kopf in die Tür und fragen, ob es was zu tun gibt. Ignorieren kann ein solches System die Anfragen nicht, sondern muss sie zwingend bearbeiten und beantworten. Klar, dass das belastend wirkt und die hohe Last die Arbeitsabläufe verlangsamt.

Ereignisbasisierte Prozesskopplung schafft Abhilfe

Die beste Lösung für flaschenpost SE war deshalb ein Umbau der Software zu einer ereignisbasierten Prozesskopplung, in der konkrete Dienste im Netzwerk eines Unternehmens über Datenbusse zur Verfügung gestellt werden (sog. Enterprise Service Bus). Simpel ausgedrückt heißt das: Erst wenn Kommissionierungsaufträge ins System eingehen, werden andere Prozesselemente in Gang gesetzt. Ihre regelmäßigen Anfragen an die Zentrale werden überflüssig. Anders gesagt: Der:die Abteilungsleiter:in hat wieder Ruhe. „Das ist eine sehr grundlegende Änderung der Technologie und eine völlig neue Art und Weise, über Software nachzudenken. Unserem Kunden öffnete das ganz neue Türen für die Skalierung seines Geschäftsmodells“, sagt Software-Architekt Michael von 5Minds IT-Solutions, der als Teamleiter die Prozessoptimierung in der Warenbewegung entwickelt hat.

Ein zweiter wichtiger Schritt, der die Effizienz der Warenbewegung bei der flaschenpost SE drastisch erhöht hat, war der Umbau der Software auf Micro-Services. Dazu wurden die Prozesselemente zunächst analysiert und isoliert, um sie anschließend in Einzelbereiche zu zerschneiden. „Mit dieser Technik machen wir monolithische Software wieder beherrschbar. Die Komplexität der Services reduziert sich, weil jeder Einzelne dieser Dienste nur noch Teilaufgaben bewältigen muss, die dann vergleichsweise einfach zu erledigen sind“, sagt Michael. Die Aufgabenlast wurde dadurch auf mehrere Pfeiler verteilt und die Gefahr eines Totalzusammenbruchs der Software ausgeschlossen.
Ein Micro-Service war fortan nur noch für die Kommissionierung zuständig, ein anderer für das Management der Lagerplätze, ein dritter kümmerte sich jetzt um die Bezeichnung der einzelnen Artikel. Jeder dieser Dienste war nun in der Lage, seine Aufgabe zu erfüllen, ohne ständig Informationen aus den übrigen Prozesselementen abfragen zu müssen oder seine eigene Tätigkeit mit den anderen abzustimmen. Beim monolithischen Software-Ansatz ging jeder Prozessschritt nur Hand in Hand mit den übrigen Elementen mit der Gefahr, dass ein kleines Straucheln in einem Bereich das gesamte System zum Sturz bringen konnte.

In der Praxis erlaubte diese Umstellung eine enorme Optimierung der Arbeitsabläufe. Beispiel Warenausgang: Vor dem Umbau musste jeder Artikel, der kommissioniert wurde, durch ein prozessuales und gleichzeitig technologisches Nadelöhr. Es gab einen Arbeitsplatz pro Lager, an dem jedes Produkt vor seiner Auslieferung gescannt wurde, um seine Kommissionierung zu registrieren und ein Etikett zu drucken. Wurden Dutzende Kommissionierungen im Lager parallel ausgeführt, weil viele Bestellungen gleichzeitig eingegangen waren, staute sich zwangsläufig die Ware vor dem Scanner.
Doch all das ist Schnee von gestern. Durch die neue Architektur konnte nun jedem Kommissionierer ein eigener Scanner an die Hand gegeben werden, sodass dutzende Vorgänge parallel registriert und Etiketten gedruckt werden können. Möglich ist jetzt auch die Kombination von Kommissionieraufträgen mithilfe eines gemeinsam neu entwickelten Algorithmus. Das bedeutet, dass ein:e Mitarbeiter:in sich nicht mehr zwangsläufig allein um eine Bestellung kümmert. Stattdessen bearbeiten alle Kommissionär:innen alle Aufträge gleichzeitig – so effizient, wie es die Software ermittelt. Wenn also Mitarbeiter:in A am Lagerplatz XY Ware für drei, vier oder mehr Bestellungen aufnehmen kann, dann sparen sich die anderen Kommissionär:innen den Weg zu Lagerplatz XY und umgekehrt.

"Nicht auf Lager"? Gibt's nicht bei flaschenpost SE

flaschenpost SE gewinnt in der Kombination all dieser Neuerungen enorm viel Zeit bei der Warenbewegung in den Lagern. Die Kommissionierungen laufen schneller, weil es keine Stauungen mehr gibt. Die unmittelbare Registrierung eines Warenausgangs aktualisiert zudem den Lagerbestand in Echtzeit. Nötige Bestellungen, um das eigene Lager aufzustocken, können unmittelbar ausgeführt werden. „Nicht auf Lager“ gibt es nicht mehr. Unter dem Strich hat flaschenpost SE durch die Umstellung nur Vorteile: Höhere Effizienz, geringere Personalkosten, weniger Fehlerquellen, noch größere Verlässlichkeit und beliebige Skalierbarkeit.

Steht Dein Unternehmen vor einer ähnlichen Herausforderung?

Du möchtest mehr über das Projekt, die eingesetzten Methoden sowie Technologien erfahren?
Sprich mich gerne an!

Felix Schymanski

Felix Schymanski

Key Account Manager