Transformationsprojekte und Agilität – Wie passt das zusammen?
„Nur ein gut aufgesetztes Projekt kann ein erfolgreiches Projekt werden“, betont ein Kollege von mir bei adesso orange sehr gerne. Damit meint er, dass man sich bereits bei der Entstehung einer Idee für ein Projektvorhaben mit der Ausgestaltung der Umsetzung beschäftigen sollte: Welche Liefertermine sind erforderlich? Welche Meilensteine? Welche Phasen gibt es? Wie muss das Projektteam aussehen, um alle Facetten abzudecken? Wird die Umsetzung agil gestaltet? Besonders bei einer S/4HANA Transformation findet man in dieser jungen Lebenszeit des Projekts selten finale Antworten auf diese Fragen. Die hohe Komplexität des Vorhabens, viele beteiligte Akteure und Stakeholder sowie der Change für den End-user in der Bedienung des Systems prägen diese Projekte. Unter diesen Rahmenbedingungen lohnt es sich, außerhalb bisheriger Herangehensweisen zu denken und für jeden Abschnitt des Projekts das Vorhaben neu zu hinterfragen.
Was heißt es, „teilagil“ bzw. hybrid zu arbeiten?
Die Entscheidung für agiles oder klassisches Projektmanagement ist geprägt davon, diese beiden Vorgehen als Gegensätze zu sehen. Dabei wird oft auf sehr kategorische Unterscheidungskriterien zurückgegriffen: Feste Liefertermine oder klare Anforderungen sind oftmals Kriterien für die Wahl der klassischen Projektmanagement-Methoden wie Wasserfall. In vielen Projekten erfolgt auf der anderen Seite die Wahl agiler Vorgehensweisen eher aus strategischen Gesichtspunkten: Es soll in allen Geschäftsbereichen agiler gearbeitet werden, um den Anforderungen der VUCA World (VUCA steht für „volatility“, „uncertainty“, „complexity“ und „ambiguity“) gerecht zu werden. Ein sinnvoller Entscheidungsprozess für ein passendes methodisches Vorgehen liegt oftmals nicht zugrunde. Dies zeigt auch ein Blick in diverse Berichte gescheiterter agiler Projekte. Häufig genannter Grund für das Scheitern eines agilen Vorhabens sind mangelnde Rahmenbedingungen und der Versuch, agile Arbeitsweisen zu adaptieren, ohne zu verstehen warum und wofür dies im Kontext sinnvoll ist. Agiles Arbeiten unterscheidet sich grundsätzlich von klassischen Ansätzen und erfordert eine entsprechende Vorbereitung der im Projekt beteiligten und betroffenen Organisation. Dazu gehört insbesondere eine umfassende Qualifizierung des Projektteams und der Einsatz von methodischen Begleitern, wie Scrum Master und agile Coaches.
Es rät sich somit, der Entscheidung für den Einsatz agiler Methoden und Vorgehensweisen mehr Beachtung zu schenken und sie differenzierter zu betrachten als „klassisch vs. agil“: Wann sind Anforderungen schon vollständig bekannt und klar? Wie geht das Projekt mit Änderungen in den Anforderungen oder auch neuen Erkenntnissen im Projektverlauf um? Ein fester Liefertermin hindert das Projektvorhaben zudem nicht daran, bereits früh Arbeitspakete fertig zu stellen und diese als „potenziell releasefähig“, wie es bspw. Scrum vorsieht, abzuschließen. Die sinnvolle Einbettung agiler Vorgehensweisen in das Projektvorhaben wird damit zum wichtigen Thema.
Wo sind agile Vorgehensweisen sinnvoll?
In einem Projekt kommen verschiedene Akteure, Entscheidungen, Interessen, Strategien und weitere Aspekte zusammen. Um die passende Vorgehensweise dafür zu identifizieren, kann das sog. Cynefin Framework helfen. Dieses ordnet ein Vorhaben in vier verschiedene Kategorien ein: einfach, kompliziert, komplex und chaotisch. Diese Einstufung soll einen Anhaltspunkt geben, wie der Lösungsweg zu einem Problem gestaltet sein sollte, um zu einer passenden Lösung zu gelangen. In den meisten Projekten, gerade im SAP Kontext, finden wir uns in den Bereichen kompliziert und komplex wieder.
Komplizierten Problemstellungen liegt der Zusammenhang zwischen Ursache und Wirkung zugrunde und lässt sich durch die richtigen Expert:innen analysieren und damit lösen. Die Vorgehensweise lautet damit: „erkennen – analysieren – reagieren“. Auf der anderen Seite kommen im komplexen Bereich so viele unbekannte Variablen zusammen, dass eine Kausalkette nicht vorzufinden ist und die Analyse von möglichen Lösungen nicht mehr zum Ziel führt. Die passende Vorgehensweise hier ist: „ausprobieren – erkennen – reagieren“.
Und jetzt? Bei der Einordnung mit dem Cynefin Framework geht es nicht darum, kategorisch das gesamte Projekt zu betrachten, die Vorgehensweise festzulegen und diese dann unreflektiert durchzuziehen. Vielmehr geht es darum zu erkennen, dass sich das Projektvorhaben in bestimmten Phasen mit Problemen beschäftigt, deren Einordnung individuell zu betrachten ist. Wir begegnen in unseren S/4HANA Transformationen in der Regel komplizierten und komplexen Problemen und brauchen daher eine Vorgehensweise, die beide Ansätze ermöglicht. Agile Vorgehensweisen zeigen ihre Vorteile insbesondere im komplexen Bereich, aber auch im komplizierten. Das Scrum Framework ermöglicht es bspw., beide Bereiche abzudecken. Die erforderliche Einstellung eines Prozesses im Customizing kann identifiziert, analysiert, beschrieben und im Sprint umgesetzt werden. Bei einem anderen Prozess kann allerdings eine Einstellung im Sprint grundausgeprägt, anschließend reflektiert und dann in einem folgenden Sprint korrigiert ausgeprägt werden.
Üblicherweise zeichnet sich in der Praxis ab, dass es zu Projektbeginn eine fokussierte Phase gibt, in der strategische Fragen geklärt und Grobkonzepte erstellt werden, um den Rahmen des Projekts zu beschreiben, Abhängigkeiten aufzuzeigen und die Richtung sowie den Scope zu schärfen. Auf dieser höheren Flugebene ermöglicht das Vorgehen „erkennen – analysieren – reagieren“, grundsätzliche Rahmenbedingungen zu definieren und das Projekt aufzusetzen. Eine agile Vorgehensweise wie Scrum ist an dieser Stelle noch nicht sinnvoll, da noch keine konkreten Arbeitspakete abgeschlossen werden können. Diese Phase ist geprägt von Workshops und kooperativen Zusammenarbeit über verschiedene Bereiche des Projekts hinweg. Diese Phase sollte kurz gehalten werden, um früh ins Handeln und in die Feedbackschleife mit dem Anwender zu gehen. Im weiteren Projektverlauf ist es dann sinnvoll, direkt im Anschluss an die Grobkonzeptphase mit Scrum zu starten. Das Grobkonzept gibt den Rahmen für das Product Backlog, welches iterativ (d. h. sich wiederholend) und inkrementell (d. h. kleinteilig, handhabbar) erarbeitet, fein konzipiert, abgestimmt und umgesetzt werden kann. Klarer Vorteil hierbei ist, dass bereits zu einem frühen Zeitpunkt der Umsetzungsphase erste Arbeitspakete abgeschlossen werden können. Das reduziert das Risiko unerledigter Arbeit und sorgt durch Fokussierung für Effizienz in der Abarbeitung. Auch wenn der GoLive zum Projektende mittels eines Big Bangs erfolgt, so ist des dennoch möglich, mittels sinnvollem Einsatz agiler Vorgehensweisen auf dem Weg dahin …
… flexibler auf neue Erkenntnisse und Kurskorrekturen zu reagieren
… schrittweise gemeinsam mit dem User die optimalen Prozesse erkennen
… unnötige Schnörkel zu vermeiden und sich auf das wesentliche zu konzentrieren
… und vieles mehr.
„Teilagiles“ Projektvorgehen in S/4HANA Transformationen
Die Frage, inwiefern agile Vorgehensweisen in eher klassischen Projekten kombiniert werden können, kommt auch an dem derzeit heißen Thema in der SAP-Branche nicht vorbei: den Transformationen vom Release R/3 ECC auf das S/4HANA. Diese Projekte bringen eine besondere Komplexität mit sich. Die Benutzeroberfläche ändert sich grundlegend, die bekannte transaktionale wechselt auf eine prozessuale Benutzerführung und Technologien werden teilweise in die Cloud umgezogen. In diesen Projekten erfolgt ein Change auf vielen Ebenen.
Für diese Herausforderung setzen wir auf unser Framework adesso active transformation, angelehnt an SAP Activate, in dem auch der teilagile Ansatz seinen Platz findet. Das gesamte Projekt ist dabei so aufgesetzt, dass der Wechsel der Produktivumgebung von alt nach neu oftmals nur als Big Bang in der laufenden Systemnutzung sinnvoll umsetzbar ist. Die Projektphasen auf dem Weg dahin bieten jedoch die Möglichkeit, agile Vorteile zu nutzen. Das Projekt startet der Phase Enterprise Discover, mit dem Ziel, die strategische Ausrichtung des Projekts (z. B. „Back to standard“) zu schärfen. In der darauffolgenden Phase Prepare wird u. a. der den sog. Transformationspfad finalisiert, also der Weg von alt nach neu. Weiterhin entstehen hier Grobkonzepte, die den fachlichen und technischen Rahmen abstecken. Die darauffolgenden Phasen Explore (Detaillierung der erforderlichen Umsetzungen in Feinkonzepten) und Realize (Umsetzung von Customizing, Entwicklung und Migration) können bei sinnvollen Rahmenbedingungen verschmolzen und mit Scrum umgesetzt werden. Die Feinkonzepte entstehen dabei im Refinement und sobald diese umsetzungsreif sind, kann die Einplanung in einen Sprint erfolgen. Hierbei ist der Anspruch, bereits früh potenziell releasefähige Arbeitspakete auf einer Qualitätssicherungsumgebung abzuschließen. Anschließend erfolgt der GoLive begleitet durch ein klassisches Cut Over Management bis hin zur produktiven Nutzung in der Phase Run.
Bei diesen Projekten kann auch die Datenmigration im Zuge der Transformation – abhängig vom Transformationspfad – einem agilen Ansatz folgen. Das Datenmodell eines ERP Systems ist hoch komplex. Es ist nahezu unmöglich, dass die Abhängigkeiten der Daten mittels „analysieren – erkennen – reagieren“ einmalig in einer Datenüberführung umzusetzen. In der Praxis kommen dafür Testmigrationen zum Einsatz, die mit steigendem Qualitätsanspruch durch meist 2–3 Iterationen der Migration schrittweise zum gewünschten Ergebnis verhelfen. Eine erste Testmigration kann bspw. mittels „ausprobieren – erkennen – reagieren“ erfolgen, um den kritischen Pfad zu identifizieren und entsprechend auf eine Lösung hinzuwirken. Mit weiteren Testzyklen steigert sich damit die Qualität und reduziert schrittweise die Komplexität, insbesondere im Hinblick auf Abhängigkeiten.
Das Wichtigste in aller Kürze:
- „Nur ein gut aufgesetztes Projekt, kann ein erfolgreiches Projekt werden“ und das Aufsetzen eines Projekts ist nicht an dessen Beginn final abgeschlossen.
- Die Vorgehensweise und Methodik einer jeden Projektphase zu hinterfragen hilft uns, die passenden Lösungswege zu finden und fokussiert anzugehen.
- S/4HANA Transformationen sind komplexe Unterfangen, in denen ein agiles Mindset dabei hilft, auf die schrittweise gewonnenen Erkenntnisse zu reagieren.
Neugierig geworden? Fragen zur agilem Arbeiten im SAP Kontext oder zu unserer Vorgehensweise in S/4HANA Transformationen? Dann kontaktieren Sie uns gerne.
