Agilität in der Logistik oder: Liefern wie Amazon

Bei der Umsetzung umfassender IT-Projekte in der Logistik sind häufig viele Anforderungen bereits vorgedacht und z. B. in einem Lasten- oder Pflichtenheft festgehalten. Eine große Anzahl an Funktionalitäten ist beschrieben – mit teilweise hohem Detailgrad. Ähnlich verhält es sich mit den zeitlichen Rahmenbedingungen. Sie sind durch fixe Releases und Meilensteinpläne abgesteckt, harte Deadlines säumen den Weg zum Projektabschluss, die Aufwände sind genau abgeschätzt. Gemäß diesen Bedingungen werden auch die Teams geschnitten, häufig chronologisch anhand der Komponenten, die den Prozess abbilden (z. B. Stammdaten, Wareneingang, Warenausgang, Finanzen).In der Realität verändert sich aber häufig der Kontext: Der Scope erweitert sich. Entsprechend wird – wenn möglich – die Mannschaft vergrößert. Ungeplantes tritt auf (Bugs, Integrationsprobleme etc.) und es muss schnell neu geplant werden (Zeit, Ressourcen, Scope). Meistens bedingen diese Veränderungen, dass eine detaillierte, langfristige Planung zu Inflexibilität und Konfusion führt. In vielen Projekten fragt man sich: „Was ist eigentlich das große Ganze?“ Man erkennt vor lauter Bäumen den Wald nicht mehr.

Wenn langfristige Planung auf kurzfristige Realitäten trifft

Sobald sich das Umfeld verändert, ist auch ein ausgeklügelter Plan in Gefahr. Galt er zu Beginn noch als praktische Orientierungshilfe, so entwickelt er sich nun häufig zu einem ungeliebten Verwaltungsgegenstand, der von Steering Meeting zu Steering Meeting immer wieder angepasst werden muss – häufig verbunden mit einem steigenden Frustrationslevel aller eingebundenen Parteien.Und dann führt eines zum anderen: Immer mehr Änderungen gefährden das Projekt. Der Scope ändert sich erneut, es wird ständig umpriorisiert, Go-lives werden mit Fake-Tests realisiert, um die Produktqualität annähernd zu erreichen. Am Ende steht mehr Halbfertiges als Vollwertiges.Gerade Teamleiter und Entwickler im skalierten Umfeld stellen sich in diesem Zusammenhang dann häufig Fragen wie:

  • Was ist tatsächlich noch umzusetzen?
  • Wo stehen wir mit unserem Arbeitsvorrat?
  • Was sind die wichtigsten Anforderungen, die die Funktionalität sicherstellen?

How to: Den roten Faden im Rauschen wieder aufnehmen

Es gibt Wege, um diesem Chaos besser zu begegnen und auch bereits laufende Projekte noch in die richtigen Bahnen zu lenken. Dabei gilt es, zunächst folgende drei Aspekte zu hinterfragen:

  • Was an Funktionalität ist wirklich wichtig für unseren End User?
  • Wie können wir das möglichst schnell validieren?
  • Welche Voraussetzungen hinsichtlich Infrastruktur und Skills müssen wir dafür schaffen?

Mit dem Beantworten dieser Fragen lässt sich der Fokus zurückgewinnen. Häufig werden so Lösungsansätze auf unterschiedlichen Ebenen erkennbar: dass zum Beispiel Colocation erheblich zur Kommunikation und zum Wert des Projektes beitragen kann oder dass die Zusammenarbeit zwischen den Spezialisten, die Business Value schaffen, so eng wie möglich gestaltet werden sollte.ERP-Umgebungen stellen in ihrer Komplexität eine eigene Herausforderung dar. Hier gilt es, viele Systeme und Schnittstellen einzubetten. Agilität ist genau für dieses Umfeld erfunden worden: mit wackligem Boden unter den Füßen die richtigen Entscheidungen treffen zu können.

Rückbesinnung auf das Wesentliche

Folgende Denkweisen haben sich durchgesetzt, um auch Projekte unter Druck erfolgreich an den Markt bringen zu können:

  • Definieren von End-to-End-Prozessen: Was sind die Pfade, die von den größten Nutzergruppen am häufigsten beschritten werden?
  • Teams um diese Prozess-Funktionalitäten herum aufstellen: Was braucht es, um einen End-to-End-Prozess zu entwickeln?

Als guter Startpunkt erwies sich dabei eine Fokussierung auf überschaubare Prozesse, um nicht „im Angesicht des Arbeitsberges“ zu erstarren und hektisch zu werden. Dazu gehören z. B. manuelles Handling, bei dem der Nutzer bestimmte Schritte selbst ausführt. Daraus folgt eine erhebliche Verkürzung der Entwicklungsdauer. Durch Feedback bei der Nutzung erfahre ich, ob sich eine Automatisierung lohnen würde.Ein anderer Fokus kann der Durchstich sein: Die Entwicklung orientiert sich dabei an einem Prozess, einer Nutzergruppe, einer Schnittstelle. Das fordert Mut, wird aber belohnt: Nutzer bekommen ein schlankes System, das ihre wichtigsten Anforderungen abdeckt (nur die größte Produktgruppe kann reklamiert werden, lediglich Standardversand ist möglich ...).Im Grunde verhält es sich wie mit der Zubereitung eines Drei-Gänge-Menüs: Wenn ich als Koch mit meiner Mannschaft beginne, alle Gänge gleichzeitig zuzubereiten, und dabei den Fokus verliere, ist die Zeit um, bevor ich meinen Gästen etwas servieren kann. Wenn ich aber zuerst einen klaren Fokus auf das Entrèe setze, während ich bereits die Experten auf den Hauptgang einschwöre und anschließend die volle Aufmerksamkeit dem Dessert widme, dann steigt die Wahrscheinlichkeit, dass die Geschichte mit einem Hochgenuss endet. Studien zeigen wiederholt, dass Multitasking lediglich zu einem schnellen Hin- und Herspringen zwischen verschiedenen Aufgaben führt, was in Summe aber nur hohe Energieverluste nach sich zieht.Um diese Aufgabe als Führungskraft zu bewältigen, kann Agilität Fokus erzeugen. Besonders Kanban-Systeme und schlichtes „Transparent-Machen“ können zu mehr Flexibilität führen und bereits in kurzer Zeit dabei helfen, beträchtliche Wertsteigerungen zu generieren.Was hat das mit Amazon zu tun? Vor 20 Jahren hat Amazon damit begonnen, Bücher zu verkaufen, der Prozess des Kaufens ist bis heute unverändert. Ich wähle ein Produkt und bestätige den Kauf zu bestimmten Bedingungen.Heute haben wir ein Vielfaches an Möglichkeiten, die Kernfunktionalität wird aber immer gewährleistet sein.Foto: CC0 Creative Commons, von chuttersnap auf Unsplash

Projektmanagement
Change
Digitale Transformation
Paul Haase
January 9, 2019

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen
BG

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?
BG

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?

Scrum by the book - Die Power agiler Prinzipien
BG

Scrum by the book - Die Power agiler Prinzipien

Organisieren für das Dringliche – oder der Verlust des Wesentlichen
BG

Organisieren für das Dringliche – oder der Verlust des Wesentlichen

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode
BG

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode

Statt einer Rezension – OKR als Rezept
BG

Statt einer Rezension – OKR als Rezept

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren
BG

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen
BG

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt
BG

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt

FRAGE: Warum macht ihr eigentlich kein SAFe®?
Boris Gloger

FRAGE: Warum macht ihr eigentlich kein SAFe®?

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?
Boris Gloger

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?
Boris Gloger

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?