Case Study – flaschenpost

Effizient geplant, schnell geliefert

Prozessbasierte Software für die flexible Tourenplanung der flaschenpost

flaschenpost-logo-referenz

Case Study – flaschenpost

Effizient geplant, schnell geliefert

Prozessbasierte Software für die flexible Tourenplanung der flaschenpost

Flaschenpost

Prozessbasierte Software für die flexible Tourenplanung der flaschenpost

Der Getränkelieferdienst flaschenpost ist seit Jahren auf starkem Wachstumskurs. Mit der Expansion wurde jedoch die Herausforderung immer größer, dass Mitarbeiter:innen im Dickicht der komplexen Prozesse die Übersicht behalten, um Touren effizient zu planen. Damit die Kommunikation und somit die Optimierung von Abläufen weiterhin reibungslos funktionieren, brauchte es eine moderne Softwarelösung unter technischer Leitung von 5Minds.

Die Skalierbarkeit der Prozesse wurde zunehmend mühsam, weil die monolithische Architektur der Anwendung nötige Anpassungen und neue Features nur noch mit hohem Aufwand erlaubte.

Eine Marktlücke, ein Geschäftsmodell und ein paar talentierte Programmierer:innen: Als das Gründerteam der flaschenpost 2012 im westfälischen Münster damit begann, seinen Kund:innen Wasserkisten und Biervorräte frei Haus bis vor deren Wohnungstüren zu liefern (und das Leergut wieder mitzunehmen), war die bundesweite Expansion des jungen Start-ups noch nicht abzusehen. Einige Jahre später klopft die flaschenpost an Haustüren in mehr als zwei Dutzend Städten des Landes. Doch die Grundzutaten ihres Erfolges reichen längst nicht mehr aus, um die stetig wachsende Logistik für die Verarbeitung von sieben Millionen Bestellungen pro Jahr reibungslos zu organisieren.

Mit der steigenden Zahl an Standorten waren die Programmierer:innen im Haus nicht nur gezwungen, ihren Quellcode zur Tourenplanung stetig zu pflegen und zu erweitern, sondern damit auch zu verkomplizieren. Mit erheblichen Folgen für das gesamte Unternehmen: Die Skalierbarkeit der Prozesse wurde zunehmend mühsam, weil die monolithische Architektur der Anwendung nötige Anpassungen und neue Features nur noch mit hohem Aufwand erlaubte. Je länger der Quellcode wurde, desto geringer wurde die Zahl der Mitarbeiter:innen, die ihn verstanden.

Das ist die FLASCHENPOST

  • Rechtsform: Europäische Aktiengesellschaft
  • Gegründet: 2012 in Münster
  • Aufnahme des Regelbetriebs: 2016
  • Jahresumsatz 2020: rund 200 Millionen Euro
  • Lieferungen in: 27 Städten
  • Anzahl der Lager: 32
  • Mitarbeiter: 7.000
  • Lieferfahrzeuge: rund 1.300
  • Jährliche Bestellungen: 7.000.000
  • seit 2020 Teil der Dr. August Oetker KG

Neues IT-Personal sah sich mit der Mammutaufgabe konfrontiert, die Komplexität und die Zusammenhänge von 100.000 Zeilen Programmcode zu entschlüsseln. Mehr noch verloren Mitarbeiter:innen ohne spezielle IT-Kenntnisse die Fähigkeit, präzise auf die digitalen Schlüsselstellen in der Tourenplanung hinweisen zu können. Sie hatten die Übersicht verloren, wann die Software welches Problem löst. Die IT-Fachleute aber waren auf diesen Input zwingend angewiesen, um die Logistik auf Basis der Erfahrungen und Schlussfolgerungen aus dem operativen Geschäft im Quellcode abbilden zu können.

Prozesse für alle Mitarbeiter:innen verständlich machen

Ziel: beliebige Skalierung des Geschäftsmodells auf simple Weise

Im Februar 2020 entscheidet sich die flaschenpost zu einer Generalüberholung ihrer Software. Das Ziel: Sie möchte eine beliebige Skalierung des Geschäftsmodells auf simple Weise ermöglichen. Das Unternehmen will dazu seine interne Kommunikation erleichtern, indem es seine Mitarbeiter:innen, vor allem auch die vielen Nicht-Techniker:innen befähigt, die Prozessabläufe detailliert zu verstehen. Sie sucht nach einem geeigneten Partner und findet uns, 5Minds IT-Solutions.

Wir setzen auf eine ganzheitliche Lösung und starten zunächst mit der Modellierung der Tourenplanung, d. h. einzelner Arbeitsabläufe. Denn zunächst geht es darum, die operativen Herausforderungen bildlich so darzustellen, dass ihre jeweilige Funktionalität und Bedeutung für den gesamten Ablauf für alle Mitarbeiter:innen nachvollziehbar sind. Um die Prozesse, die sich aus einzelnen Bausteinen, sogenannte Events zusammensetzen, und die Notwendigkeit ihrer Reihenfolge zu verstehen, nutzen wir gemeinsam mit der flaschenpost eine grafische Spezifikationssprache, Business Process Model and Notation (BPMN). „Wir kommunizieren mit Leuten aus Fachabteilungen, die die Programmiersprache nicht sprechen, aber deren Anliegen wir umsetzen müssen“, sagt Daniel Heise, Head of Engineering bei 5Minds. „BPMN versetzt uns in die Lage, die sprachlichen Missverständnisse auszuschließen.“

Flaschenpost
Daniel Heise unterstützt die flaschenpost bei der Modellierung der Tourenplanung in BPMN

Statt die digitalen Abläufe als monolithischen Block anzulegen, lassen wir Mitarbeiter:innen der flaschenpost einzelne Prozessschritte in BPMN beschreiben. Daraus erstellen wir Module, die jeweils einen bestimmten Schritt innerhalb des Prozesses abbilden, und platzieren sie dann im Gesamtkonzept. Die Aufgaben der jeweiligen Module können jetzt ganz einfach identifiziert werden, und der zermürbend lange Quellcode ist verbannt.

Basis für eine maximale Lieferzeit von 120 Minuten

Die Tourenplanung der flaschenpost besteht aus drei Phasen. Es beginnt mit der Datenerhebung. Wie viele Bestellungen gibt es? Wie viele Fahrzeuge und Ladeplätze stehen zur Verfügung? Dazu müssen die Fahrer:innen ihre jeweiligen Arbeitsschritte mithilfe einer Applikation dokumentieren, um dem System ihre Verfügbarkeit zu signalisieren. Danach beginnt die eigentliche Planungsphase, in der Verkehrsdaten verwendet werden, um möglichen Staus aus dem Weg zu gehen.

Anhand von Richtwerten für das Beladen, die Fahrstrecke und die Lieferung an Kund:innen bietet die Software eine geschätzte Ankunftszeit (Estimated Time for Arrival), die ständig und für Kund:innen einsehbar aktualisiert wird. Wenn es bei einer Tour zu Verzögerungen oder Beschleunigungen kommt, werden Kund:innen sofort informiert. Die Touren werden dabei so geplant, dass die Fahrtstrecken die schnellstmögliche Routen berücksichtigen, die alle Lieferadressen miteinander verbinden. Das schafft die Basis dafür, dass die Fahrer:innen die versprochene Lieferzeit von maximal 120 Minuten einhalten können. Im sogenannten „post processing“ – Phase drei – werden Trips aussortiert, die zu wenig Bestellungen haben oder Kund:innen zu spät erreichen. Um zu verhindern, dass eine Bestellung immer wieder aus der Planung geworfen wird, markiert sie die Software mit steigender Priorität.

Erst nach der visuellen Modellierung der Prozesse reichern wir sie im zweiten Schritt technologisch an, füllen sie also mit Programmcode, um die Prozesse tatsächlich auch ausführen zu können. Der Prozess der Tourenplanung besteht aus mehreren Unterprozessen. Auch hier hilft die Visualisierung, um die tieferen Ebenen der Software anschaulich darzustellen. Die Vorteile für das Unternehmen liegen auf der Hand. Die IT kann mit allen Abteilungen bis an die Wurzel ihrer Prozesse heranrücken, um sie auch mit Nicht-Techniker:innen zu analysieren, diskutieren und optimieren.

Flaschenpost
Die Ankunftszeit der Bestellung wird mit Hilfe der entwickelten Software direkt für den Kunden ermittelt

Ergebnis:

Software, die mit dem Unternehmenswachstum auf Gleichschritt bleibt

Daniel Heise: „Die Skalierung geht simpel vonstatten“

„Die Verbildlichung und die Isolierung von Prozessschritten in einzelne Aufgaben gibt der flaschenpost die Möglichkeit, diese Aufgaben beliebig zu verschieben, um sich z. B. auf Änderungen am Markt einzustellen. Wir können einzelne Prozessschritte auch entfernen oder vervielfältigen, ohne dass der Gesamtprozess darunter leidet“, erklärt Daniel Heise. Das bedeutet in der Praxis zweierlei: zum einen, dass die Skalierung simpel vonstatten geht. Ein stark wachsendes Unternehmen kann seine Software also im Gleichschritt auf Stand bringen. Es muss nicht darauf warten, bis der Quellcode den neuen Anforderungen genügt. „An dieser Stelle entsteht die Basis für das Wachstum der flaschenpost“, sagt Heise.

Zum anderen macht sich das Unternehmen unabhängiger von seiner IT-Infrastruktur, weil die Module über die Cloud auf verschiedenen Servern verteilt werden können. Eine einzelne Anwendung dagegen kann einen Server schnell an seine Kapazitätsgrenze treiben und die Gefahr von Ausfällen drastisch erhöhen. Weil zudem jederzeit einsehbar ist, was die Software gerade macht und jeder Mitarbeiter erkennen kann, welches Event gerade läuft, verbessert sich das Monitoring exponentiell und nötige Verbesserungen können mühelos identifiziert werden.

Sie stehen vor einer ähnlichen Herausforderung?

Sie möchten mehr über das Projekt, die eingesetzten Methoden sowie Technologien erfahren?
Sprechen Sie mich gerne an!

Daniel Heise

Daniel Heise

Head of Engineering