Minimum Viable Change als Kompass für erfolgreiche Retrofits und Greenfield-Projekte

Irgendwas mit Agile ist eigentlich immer. Doch in diesem Beitrag soll es nicht darum gehen, die nächste Drei-Wort-Kombination als Allheilmittel zu preisen. Stattdessen geht es um Lösungsansätze, Komplexität und die sieben Rs der Logistik, die durch eine gar nicht so neue Linse betrachtet werden.

Minimum Viable Change (MVC) bezeichnet den kleinstmöglichen, aber sinnvollen Eingriff in bestehende Prozesse oder Systeme, um einen messbaren Fortschritt in Richtung eines definierten Ziels zu erzielen. Es geht dabei nicht um das Prinzip des „kleinsten gemeinsamen Nenners“, sondern um die gezielte Reduktion auf das Notwendige. Anders als beim Minimum Viable Product (MVP), das einen funktionalen Prototypen mit minimalem Feature-Set zur Markterprobung beschreibt, fokussiert sich MVC auf die Steuerung von Veränderungsprozessen selbst. MVC fragt: „Was müssen wir wirklich ändern, um eine Verbesserung zu erzielen?“ – MVP fragt: „Was müssen wir mindestens liefern, damit ein Produkt nutzbar wird?“. Damit ist MVC insbesondere in komplexen, gewachsenen Systemlandschaften wie der Intralogistik von hoher Relevanz.

Die sieben Rs der Logistik sind: das richtige Produkt, zum richtigen Kunden, in der richtigen Menge, im richtigen Zustand, an den richtigen Ort, zum richtigen Zeitpunkt, zu den richtigen Kosten zu bringen. Sie sind die zentralen Messgrößen für Erfolg in der Logistik. Minimum Viable Change ist ein Kompass, um den Weg dorthin so transparent, effizient und sicher wie möglich zu gestalten. Dieser Ansatz erweitert die Perspektiven der einzelnen beteiligten Geschäftsdomänen hin zur gleichzeitig sehr einfachen und sehr komplizierten Frage: „Wieviel muss überhaupt verändert werden, um das angestrebte Ziel zu erreichen?“

Besonders in der Intralogistik führen viele Wege vom Wareneingang zum Warenausgang und viele Prozesse sind an die eigentliche Bewegung von Lagerbeständen involviert. Die Komplexität und die Versuchung eine eierlegende Wollmilchsau zu konzeptionieren sind entsprechend hoch.

Wird dem MVC Prinzip gefolgt, greift es hier bereits als Korrektiv ein. Durch die eine zentrale Frage fällt die Barriere, die durch Lasten- und Pflichtenheft sowie durch die Kunden- und Auftraggeberkonstellation entsteht. Die Antwort auf diese Frage kann nur in der Zusammenarbeit – zuerst auf der operativen Ebene und schließlich auf der strategischen – gefunden werden. Denn das Ziel ist nicht, Hard- und Software-Lösungen zu finden, die auf dem Papier fantastisch aussehen, für die dann aber in der Umsetzung Prozesse verbogen werden müssen, sondern den Prozess so gut wie möglich – aber nur so viel wie nötig – mit Unterstützung zu versehen. Dazu ist eine gemeinsame Erarbeitung des Ist- und Soll-Zustandes mit allen Beteiligten unerlässlich: Software-Expert*innen müssen sich die Prozesse von Wareneingang bis Warenausgang idealerweise vor Ort ansehen, Logistiker*innen das verfügbare digitale Werkzeug kennenlernen. Dadurch kann das „Warum“ hinter jedem Prozessschritt so beleuchtet werden, dass ein gemeinsamer Weg in die Zukunft geplant werden kann. Die initiale Planung erfolgt auf anschließend auf kollaborativen Plattformen. Mit dem Fokus auf Funktionsklarheit werden Verkettungen aufgebaut – aus ihnen entstehen Gewerke, die so schnell wie möglich getestet und operativ validiert oder eben mit den gewonnenen Erkenntnissen iteriert werden. Dieses grundlegende Vorgehen zieht sich durch alle Phasen eines Retrofits oder Greenfield-Projekts.

Sie kann unter dem Motto „Verstehen statt Vermuten“ zusammengefasst werden – idealerweise als Bringschuld für alle Projektbeteiligten. Denn jedes Projekt hat individuelle Besonderheiten, sowohl innerhalb der einzelnen Domänen als auch domänenübergreifend. Diese initiale Phase ist kritisch für alle folgenden, denn in ihr entsteht das gemeinsame Bild und vor allem die gemeinsame Sprache, auf deren Basis später die Umsetzung erfolgt. Kollaborative Projektmanagement- und Dokumentationswerkzeuge sind in diesem Schritt unerlässlich, um alle Beteiligten zu Mitgestaltenden zu machen.
Wird dem Prinzip des Minimum Viable Change gefolgt, verläuft diese Phase anders als in klassischen Pflichten- und Lastenheft-Konstellationen. Es wird nicht entlang von Funktionen gedacht, sondern von Anwendungsszenarien. So bleibt der Fokus auf dem eigentlichen Prozess. Diese Art der Planung ist die Basis für hohe Geschwindigkeit und Entscheidungssicherheit im späteren Verlauf – wo bei einem klassischen Vorgehen die ersten Fehleinschätzungen mit der harten operativen Realität kollidieren.

Sie verbindet Funktionen mit einem stützenden Gerüst und muss ebenfalls so aufgebaut sein, dass granulare Veränderungen überhaupt möglich sind. Das bedeutet, dass idealerweise die Software-Seite Zugeständnisse an die Logistik macht und deren Fachsprache als Basis für die Entwicklung wählt, sodass Logistiker*innen schnell und transparent Entscheidungen über Entwicklungsschritte treffen können. Von der Logistik-Seite muss eine Annäherung an agile Methoden erfolgen – wie sie auf Entwicklerseite üblich sind:

• Clean Architecture: Anwendungsfälle und Geschäftsregeln des Unternehmens bilden den Kern, um den herum Funktionen, Datenbanken und Nutzerinterfaces angeordnet sind. Das Besondere dabei ist, dass Abhängigkeiten nur von außen nach innen existieren dürfen. Ein Anwendungsfall ist beispielsweise die Kommunikation mit einem Dienstleister, die nach bestimmten Geschäftsregeln erfolgen muss. In Clean Architecture kann das per Mail, Telefon oder per Chat erfolgen, da die Kanäle nicht fest mit den Geschäftsregeln verbunden sind und sie daher auch nicht an eine bestimmte Infrastruktur gebunden sind.
• Test Driven Design: Vor der Software-Entwicklung werden bereits die Tests für die jeweiligen Komponenten definiert. So wird sichergestellt, dass der Code permanent mit den realweltlichen Anforderungen konfrontiert wird.
• Saubere Domänengrenzen: Gerade in monolithischen Standardlösungen kommt es oft zur Vermischung von Prozessen unterschiedlicher Domänen: So landen plötzlich Aufgaben der Buchhaltung in Logistikprozessen — und Lagermitarbeitende suchen in kilometerlangen Excel‑Listen nach den richtigen Vorgangsnummern, um Aufträge zu finalisieren.

Sie muss die Planungs- und Architekturphase abbilden können: Wenn kleinteilig, schnell und viel implementiert werden soll, muss das möglichst reibungslos passieren. „Cloud“ bedeutet in diesem Zusammenhang nicht zwangsläufig Rechenzentren bei Dritten, sondern dass Rechenleistung als Ressource – wie Strom oder Wasser – betrachtet wird. Denn physisch besteht sie aus vielen günstigen, hochvernetzten Hardwareeinheiten in Clustern. Redundanz entsteht auf Softwareebene, weil nahezu jeder Prozess — von Provisionierung über Monitoring bis Failover — automatisiert ist. Mittlerweile erlauben ausgereifte Open-Source-Systeme wie etwa Kubernetes, Infrastruktur per Code zu steuern. So wird Skalierung planbar und prüfbar, während Betriebsteams sich auf Prozess- und Qualitätsverbesserungen statt auf manuelle Infrastrukturarbeit konzentrieren können. Automatisierte Bereitstellung ist die Grundlage für reproduzierbare Qualität und Skalierbarkeit.

Hier greifen alle Teile ineinander, um eine iterative, schnelle Entwicklung getesteter und funktionaler Gewerke zu ermöglichen, die möglichst früh einen operativen Mehrwert schaffen. Weil die Kommunikationswege und vor allem die Fachsprache des Projekts bereits in den vorherigen Phasen etabliert wurden, wird das Projekt zu einem lernenden Organismus. Dafür müssen die kooperierenden Organisationen und Werkzeuge entsprechend angepasst sein. Das zeigt sich besonders bei der Integration des Warehouse-Management-Systems (WMS): Es bewegt sich zwischen verschiedenen Welten. Übergelagerte Enterprise‑Resource‑Planning-Systeme (ERP) steuern Aufträge und Buchungen, darunter liegen Subsysteme, die Maschinen, Fördertechnik und Mensch‑Maschine‑Schnittstellen definieren.

In der Mitte des WMS liegen seine Kernfunktionen:

• Bestandsführung
• Auftragssteuerung
• Nachschub
• Kommissionierung

In der Praxis sind die Grenzen individuell und oft fließend. Soll das ERP die Feindisposition übernehmen oder das WMS? Wird der Materialflussrechner (MFR) gekapselt oder direkt integriert? Diese Fragen werden durch das MVC-Prinzip und das in den vorherigen Phasen entstandene Know-how, die etablierten Workflows und die Beziehungen auf Augenhöhe bestmöglich beantwortet und auf die Umsetzbarkeit geprüft. Damit das Warehouse-Management-System das Herz des intralogistischen Organismus wird – und für Rhythmus, Versorgung und Synchronisation sorgt – muss es individuell ins Ganze eingebettet werden. Was sich fantastisch anhört, doch es bedeutet auch den Willen zu haben, Planungen und Infrastruktur zu beerdigen, wenn sie nicht (mehr) dem Prinzip der kleinsten sinnvollen Veränderung entsprechen.

Mit der Inbetriebnahme ist der Prozess nicht abgeschlossen: Unternehmen und damit ihre Logistik wachsen und wandeln sich. Im langfristigen Betrieb zeigen sich die Vorteile des MVC-Konzepts: Wenn die Teams auf beiden Seiten bestehen bleiben, sind notwendige Veränderungen schnell und effizient – und im Vergleich zu Big-Bang-Ansätzen mit deutlich weniger Kosten verbunden. Die Fähigkeit zur kontinuierlichen Veränderung ist der beste Weg, auf komplexer werdende Marktsituationen zu reagieren, ohne intern durch große Veränderungsprozesse mehr Komplexität zu erzeugen.

Voraussetzung für nachhaltigen Erfolg ist die Fähigkeit, sich an seine Umwelt anzupassen. Dafür sind Wissen, Verantwortungsbereitschaft und Vertrauen notwendig – als Basis, um Dinge ohne ideologischen oder technischen Ballast zu betrachten und zu verändern. Minimum Viable Change ist der Wegweiser, um den Prozess immer wieder im Sinne der eigenen Geschäftsprozesse zu durchlaufen – indem nur so viel wie nötig und so wenig wie möglich eingegriffen wird.