5 agile Techniken, die klassisches Projektmanagement flexibler und effektiver machen

Agile Techniken lassen sich aus meiner Erfahrung gut in einen klassischen Unternehmenskontext integrieren. Sie helfen, Projekte flexibler und effektiver – oft auch effizienter – durchzuführen. 5 agile Techniken halte ich für besonders geeignet, die klassischen Phasen der Projektdefinition, – planung und -durchführung zu unterstützen und damit final die Kundenzufriedenheit mit den Projektergebnissen zu erhöhen.

Produktbacklog

Im Produktbacklog werden die Kundenwünsche gemeinsam mit den relevanten Stakeholdern erarbeitet, auf Karten festgehalten und priorisiert. Welche Anforderungen müssen unbedingt erfüllt sein, welche Zielsetzungen sind optional und welche Themengebiete werden von vorneherein ausgeschlossen und sind nicht Bestandteil des Projektscopes? Da es zu Beginn des Projektes kaum möglich ist, alle Anforderungen zu erfassen und sich weitere Kundenwünsche erst im Laufe des Projektes herauskristallisieren, hilft es, diese Anforderungsphase möglichst kurz zu halten (1 Stunde) und als erste Basis für die Projektplanung zu nehmen.

Storyboard

Im nächsten Schritt werden weitere Fragen bearbeitet, um die Kundenanforderungen noch besser zu verstehen. Warum wird das Projekt aufgesetzt, wer ist involviert und wie soll das Projekt organisiert werden, wie sieht die Timline aus, welche Ressourcen stehen zur Verfügung, wie und mit welchen Methoden wird gearbeitet und wer ist zu informieren? Aus dieser Diskussion wird das Storyboard erstellt, dass alle bis jetzt genannten Anforderungen in Form von User Stories enthält. Diese User Stories enthalten eine kurze Beschreibung, welcher Stakeholder was mit welcher Zielsetzung erreichen möchte („Ich in meiner Rolle als … möchte, dass…., damit….“). Diese Anforderungen werden wie das Produktbacklog auf Karten dokumentiert, die dann nummeriert, zu Themengebieten (Epics) geclustert und priorisiert werden (und in einem späteren Schritt auch mit einer ersten Aufwandschätzung versehen werden).

Sprintplanung

Steht das Storyboard, das jetzt mit den User Stories alle Anforderungen sowie die grobe Vorgehensweise enthält, werden im nächsten Schritt die konkreten Arbeitspakete für die erste Umsetzungsphase – den ersten Sprint – mit dem Projektteam geplant. Im Unterschied zum klassischen Projektmanagement wird nicht das komplette Projekt detailliert durchgeplant. Der Fokus liegt auf dem ersten Sprint – jeder weitere Sprint wird in Abhängigkeit der Ergebnisse des vorangegangen Projektabschnitts geplant. Bei zeitlichen Engpässen wird im Zweifelsfall in Absprache mit dem Kunden der Anforderungskatalog reduziert. Die todos für den ersten Sprint werden im Sprint Backlog festgehalten und der Arbeitsfortschritt regelmäßig (im Idealfall täglich) über Task Boards dokumentiert.

Review und Retro

Nach jedem Sprint, der maximal 4 Wochen dauert, findet ein Feedbacktermin mit den Stakeholdern (Produkt Review) statt, auf dem die Ergebnisse des Sprints demonstriert und das Feedback der Kunden aufgenommen wird. Ebenfalls gibt es nach jedem Sprint einen Arbeitstermin mit dem Projektteam (Retrospektive). Hier wird geklärt, wie der Sprint aus prozessualer Sicht verlaufen ist und welche Verbesserungspotentiale es gibt.

Fazit

Wenn man sich von den ungewohnten Begrifflichkeiten nicht abschrecken lässt, so können einige agile Techniken auch in einem in erster Linie klassisch agierenden Unternehmen eingesetzt und die Vorteile der agilen Prinzipien, z. Bsp. intensive Zusammenarbeit mit den Stakeholdern, hohe Transparenz bzgl. des Projektfortschritts sowie flexibler und konstruktiver Umgang mit Anforderungsänderungen in die Praxis umgesetzt werden.

Erfahrungsbericht über die Einführung von Predictive Analytics

Bettina Wiegen,Erfahrungsbericht

Wie ich lernte, Big Data zu lieben – Erfahrungsbericht über die Einführung von Predictive Analytics zur automatisieren Bedarfsermittlung im eCommerce

Ausgangssituation

Als Projektleiter im Category Management eines mittelständischen Multilabel und Multichannel Einzelhändlers war ich u.a. verantwortlich für die Optimierung der Einkaufs- und Beschaffungsprozesse. Im Rahmen der digitalen Transformation stand nicht nur das Geschäftsmodell des ursprünglichen Versand und Stationär Händlers auf dem Prüfstand, sondern auch die interne Prozesslandschaft. Konkret ging es in diesem Fall um die Frage, wie die Bedarfsermittlung in der Saison – also die Einschätzung des Umsatzpotentials einzelner Artikel nach Vorliegen der ersten Abverkäufe – zum einen an die hohe Dynamik und Komplexität des eCommerce Geschäfts angepasst und zum anderen die Mitarbeiter in der Disposition durch einen möglichst hohen Automatisierungsgrad in ihren Aufgaben entlastet und unterstützt werden konnten.

Ich möchte Sie auf eine Reise mitnehmen, die mit einem grundlegenden Paradigmenwechsel im Einkauf beginnt und mit der erfolgreichen Implementierung der Hochrechnungssoftware noch lange nicht endet. Neben einer Beschreibung der Projektvorgehensweise werde ich Sie in diesem Erfahrungsbericht insbesondere an unseren „Lessons learned“ teilnehmen lassen.

Projektdefinition, -planung und -durchführung

Aufgrund der Vielzahl der Umsatztreiber (Printaktionen, eCommerce Kampagnen, Filialbeilagen, Trends etc.) und den damit verbundenen starken Nachfrageschwankungen im Zeitablauf war schnell klar, dass konventionelle Demand Planning Prognoseverfahren nicht ausreichen würden, um eine belastbare Prognose auf der Ebene Artikelgröße zu erstellen. Ebenso wurde deutlich, dass es nicht damit getan sein würde, die bestehenden Prognosetools, die sich bei der Hochrechnung der Katalogartikel bewährt hatten, zu übernehmen oder zu überarbeiten. Was nötig war, war ein grundlegender Paradigmenwechsel in der Disposition!

Die physische Warenverfügbarkeit ist im eCommerce von hoher Priorität, da sie ein Hauptkriterium für das Ranking von Produkten im Webshop ist – ohne verfügbare Ware besteht ein hohes Umsatzrisiko. Die Umsatztreiber sind multikausal und nicht mehr durch lineare, rein vergangenheitsorientierte Prognosemodelle abbildbar. Umsatzsteigernde Maßnahmen sind kurzfristig möglich und verändern den Umsatzverlauf einzelner Artikel spürbar. Für unser Projekt waren damit folgende grundsätzliche Anforderungen definiert: das Prognosetool sollte auf Basis von Big Data Anwendungen arbeiten und möglichst viele Faktoren berücksichtigen, die den Abverkauf beeinflussen, es sollte auf Basis Nachfrage (=Warenbedarf) und Retouren hochrechnen, den gesamten Lebenszyklus eines Artikels beinhalten und, um eine flexible und zeitnahe Steuerung zu unterstützen, Prognosedaten auf Ebene Woche bereitstellen.

Nach der Erarbeitung der grundlegenden konzeptionellen Anforderungen sah die Projektplanung folgende Schritte vor:

  • Anbieterauswahl
  • Feinkonzeption Dateninput und -output
  • Migration historischer Daten
  • Entwicklung Prognosemodell
  • Integrationstests
  • Go live

Bei der Anbieterauswahl kam ein Dienstleister zum Zuge, mit dem schon im Vorfeld die Möglichkeiten von Predictive Analytics und der Einsatz von maschinellem Lernen zur Verbesserung der Hochrechnungsqualität über einen längeren Zeitraum getestet worden war. Charakteristik der Predictive Analytics Verfahren ist, dass auf Basis von Datenmodellen und Algorithmen Vorhersagen getroffen werden, wie sich der Absatz in der Zukunft entwickeln kann bzw. wird. Diese Modelle werden sowohl mit Vergangenheitsdaten als auch mit Parametern, die den zukünftigen Abverkauf beeinflussen, gefüttert und trainieren und optimieren sich selber.

Die Feinkonzeption beinhaltete im Wesentlichen, mit welchen Daten das Prognosetool gespeist und welche Daten zu welchem Zeitpunkt hochgerechnet und geliefert wurden. Das umfasste natürlich auch die Frage, welche Vergangenheitsdaten wie weit zurück aufbereitet werden konnten. Die wesentlichen Schnittstellen – was sowohl den Input als auch den Output anging – mussten zu SAP gebaut werden. Darüber hinaus waren aber auch Schnittstellen zum Webshop (für Infos wie z. Bsp. Onlinestellungsdatum, Ranking, Clicks) relevant. Eine wesentliche Aufgabe des externen Dienstleisters war natürlich die Entwicklung des Prognosemodells und der entsprechenden Algorithmen. Das Modell lernte anhand der Vergangenheitsdaten und erstellte rückwirkend für die Vergangenheit zu unterschiedlichen Zeitpunkten Prognosen, die dann mit den tatsächlichen Istwerten verglichen wurden. Allerdings wurde diese Aufgabe erheblich dadurch erschwert, dass eine Vielzahl der benötigten Daten noch nicht in der neuen Struktur vorlag. Nach entsprechenden Integrationstests in die SAP Umgebung war der Go Live nach ca. 12 Monaten geplant.

Der Termin konnte auch in etwa gehalten werden. Inputdaten wurden täglich auf Ebene Artikelgröße von SAP an das Hochrechnungstool geliefert und nach einem Hochrechnungslauf auf der Maschine des Dienstleisters die entsprechenden Prognosen (Bruttoabsatz und Retouren auf Ebene Woche für einen Zeitraum von 6 Monaten) zurück an die SAP Module BW und MM geliefert. Die Hochrechnungsqualität lag anfänglich aufgrund von mangelhafter Inputdaten und Anlaufzeit, die das Modell brauchte, um die Algorithmen zu optimieren, bei ca. 50%. Diese Prozentzahl bezieht sich auf das Verhältnis von absoluter Stückabweichung der Prognose zum Istwert (retrograde Betrachtung). Mit verbessertem Dateninput und Training des Prognosemodells sind deutliche Verbesserungen zu erwarten – je nach Zeitpunkt der Prognoseerstellung liegt die Zielsetzung bei einer relativen Abweichung von maximal 20-30%.

Fazit

Im Laufe des Projektes wurden wichtige Erkenntnisse gesammelt. So wurde der durchaus kostspielige Einsatz von Predictive Analytics über einen Business Case gerechnet – Mehrumsätze durch verbesserte Warenverfügbarkeit bei gleichzeitiger Reduzierung von Beständen und Überhängen kompensierten die Kosten. Sie sollten sich fragen, ob Ihre Fragestellung so ein komplexes Tool rechtfertigt. Wenn Sie Produktdaten nicht nur im Rahmen der Artikelprognose sondern auch in Verbindung mit CRM Maßnahmen nutzen wollen oder daran denken, ein Pricingtool einzuführen, dann ergeben sich sicherlich aus der gemeinsamen Nutzung der Daten große Synergiepotentiale.

Die Messbarkeit der Prognosequalität ist unabdingbar, um sowohl das Modell ständig verbessern zu können als auch um die Akzeptanz der Prognose bei den Anwendern zu stärken. Das Modell trifft eine Aussage über das Umsatzpotential jedes einzelnen Artikels – das vorgegebene Budget limitiert weiterhin das Ordervolumen. Die Entscheidung, welche Artikel auf Basis eines automatisierten Bestellvorschlags in welchem Umfang nachgeordert werden, verbleibt beim Disponenten. Unterstützt wurde der Disponent bei dieser Entscheidung durch ein Bestandssteuerungstool, das auf Basis von Warenbedarf und Warenbereitstellung das Open-to-Buy über den gesamten Entscheidungszeitraum ausweist.

Die intensive Betreuung und Weiterentwicklung des Tools nach der Go live Phase ist essentiell. Nur durch intensives Monitoring der Hochrechnungsergebnisse und regelmäßige Feedbacks an die Entwickler des Modells ist eine Verbesserung der Hochrechnungsqualität möglich. Es empfiehlt sich auch, die Gesamtprognose über alle Artikel mit den zentralen Unternehmensprognosen zu vergleichen und damit einen ersten Plausibilitätscheck durchzuführen. Informationen zu zukünftigen (auch kurzfristigen) umsatzrelevanten Maßnahmen sollten so weit wie möglich im Prognosemodell berücksichtigt werden.

Rückblickend waren für die erfolgreiche Einführung des Projektes aus meiner Sicht 3 Faktoren ausschlaggebend. Zum einen die heterogene Zusammensetzung des Projektteams, das aus Data Scientists, Disponenten, SAP Spezialisten und unternehmensinternen IT Experten mit klaren Aufgabenverteilungen bestand. Zum anderen war die Vorarbeit in Form des Grobkonzeptes enorm wichtig, so dass allen Beteiligten schon zu Beginn des Projektes klar war, welchen Anforderungen das neue Prognosetool genügen sollte. Ebenso war eine straffe Projektorganisation und eine geregelte und offene Kommunikation zwischen internen und externen Projektbeteiligten unabdingbar für die effiziente und vertrauensvolle Zusammenarbeit. Letztendlich stand trotz aller Automatisierung und Digitalisierung der Mitarbeiter und seine Anforderungen im Mittelpunkt unseres Projektes.