Eine Marktlücke, ein Geschäftsmodell und ein paar talentierte Programmierer:innen: Als das Gründerteam der flaschenpost 2016 im westfälischen Münster damit begann, seinen Kund:innen Wasserkisten und Biervorräte innerhalb von 120 Minuten 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 200 Städten des Landes. Doch die Grundzutaten des Erfolges reichen längst nicht mehr aus, um die stetig wachsende Logistik für die Verarbeitung von mehr als zehn 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.
Das ist flaschenpost SE
- Rechtsform: Europäische Aktiengesellschaft
- Unternehmensgründung: 2016 in Münster
- Lieferungen: in fast 200 Städten
- Anzahl der Lager: 33
- Mitarbeiter:innen: rund 20.000 bundesweit
- Lieferfahrzeuge: 3.000
- Jährliche Bestellungen: über 10.000.000
- seit 2020 Teil der Dr. August Oetker KG
Das IT-Team der flaschenpost sah sich mit der Mammutaufgabe konfrontiert, mit bis zu 100.000 Zeilen Programmcode arbeiten zu müssen. Angesichts der zunehmenden Komplexität wurde es immer schwieriger, die digitalen Schlüsselstellen in der Tourenplanung zu identifizieren und präzise auslesen zu können, 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 Mitarbeitenden verständlich machen
Im Februar 2020 entscheidet sich die flaschenpost zu einer Generalüberholung ihrer Software. Das Ziel: Eine beliebige Skalierung des Geschäftsmodells auf simple Weise zu ermöglichen. Das Unternehmen will dazu seine interne Kommunikation erleichtern, indem es seine Mitarbeitenden, vor allem auch andere Fachabteilungen ohne IT-Background, die Prozessabläufe detailliert zu verstehen. Auf der Suche nach einem geeigneten Partner entscheidet sich die flaschenpost für 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 Mitarbeitenden 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, Head of Engineering bei 5Minds. „BPMN versetzt uns in die Lage, die sprachlichen Missverständnisse auszuschließen.“
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ögliche Staus zu vermeiden.
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 effizienteste Route berücksichtigen, die alle Lieferadressen miteinander verbindet. 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 Fachabteilungen bis an die Wurzel ihrer Prozesse heranrücken, um sie auch mit Mitarbeitenden ohne IT-Background analysieren, diskutieren und optimieren zu können.
Ergebnis:
Software, die mit dem Unternehmenswachstum im Gleichschritt bleibt
„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. 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 Daniel.
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.
