Etwas mehr Agilität in SAP-Projekten mit Prototypen

Das SAP-Projekt ist schnell in die üblichen Phasen aufgeteilt: Prozessanalyse, Soll-Konzeption, Umsetzung, Test, Schulung, Go-Live und Hypercare. Diese Phasen und untergeordnete Aufgaben lassen sich mit Microsoft Excel in einem Projektplan abbilden. Zu jeder Phase gibt es definierte Zeiträume, einen zu erreichenden Meilenstein, das klingt doch toll… Meiner Erfahrung nach funktioniert ein solches Vorgehen zwar in den ersten Phasen sehr gut, doch spätestens, wenn die Test-Phase beginnt wird schnell klar, dass die umgesetzte Lösung doch nicht so ganz den Anforderungen genügt. Dabei hat man sich bei der Umsetzung doch exakt an das Pflichtenheft gehalten, welches sehr aufwendig erstellt und von allen relevanten Stakeholdern “mit Blut” unterschrieben worden ist.

Ein Blick auf Wikipedia verrät: das Wasserfall-Modell ist von 1956 und meiner Meinung nach für komplexe SAP-Projekte schon lange nicht mehr “State of the Art”. Warum ist dieses Vorgehen in SAP-Projekten dennoch so verbreitet? Vorweg: Im Folgenden verwende ich Teile und Ideen von Scrum. Das bedeutet nicht, dass ich exakt nach Scrum vorgehe. Frei nach den Scrum-Autoren: “Es ist zwar möglich, nur Teile von Scrum einzusetzen – das Ergebnis ist dann aber nicht Scrum.” – Soll es an dieser Stelle auch nicht sein. Wir machen einen ersten Schritt in die agile Welt 😉

In anderen Bereichen, wie bspw. in der Webentwicklung, gehören moderne Vorgehensmodelle zum Standard. Das liegt vielleicht an einem etwas agileren Umfeld als in typischen SAP-Projekten. An dieser Stelle möchte ich dafür werben, auch in SAP-Projekten auf agile Methoden zurückzugreifen. Für ein SAP-Projekt habe ich beispielsweise die folgenden Grundsätze aufgestellt:

• Stelle den Prototyp in den Fokus. Richte dein Vorgehen darauf aus, das du frühzeitig einen lauffähigen Prototyp präsentieren und testen kannst.
• Hole dir Unterstützung vom Management für eine agile Vorgehensweise und werbe für die Prinzipien. Dir ist es bspw. wichtiger flexibel auf Veränderungen zu reagieren, als dich “blind” an einen vorgegebenen Plan zu halten (Agiles Manifest).
• Keep it simple. Verwende nicht alle Methoden und Instrumente, die du in deinem Werkzeugkasten hast, sondern nur die, die auch passen.

Warum soll ich einen oder mehrere Prototypen entwickeln? Ganz einfach: der Fachbereich bekommt etwas zum “anfassen” und kann sich frühzeitig selber ein Bild machen, ob die gestellten Anforderungen so umgesetzt worden sind, wie gewünscht. Was für dich als SAP-Berater selbstverständlich ist, nämlich aus einem abstrakten Konzept sich eine Lösung im SAP-System vorzustellen, ist für andere Personen mitunter nicht so einfach möglich. Das liegt zum Beispiel daran, dass ein SAP-Projekt für dich zum Alltag gehört, für den Fachbereich aber eher die Ausnahme darstellt. Aber in SAP ist doch alles miteinander verknüpft. Geht das überhaupt, nur einen Teil zu entwickeln und vorzustellen? Ja klar geht das.

Starte damit, dass du die Anzahl an Prototypen in deinem Projekt festlegst. Konkreter meine ich damit einen Prototyp, der iterativ erweitert und verbessert wird. Bei einem neuen Prototyp ca. alle acht Wochen und einer grob geschätzten Projektlaufzeit von einem Jahr kannst du dich beispielsweise für sechs Prototypen entscheiden. Der letzte Prototyp ist das fertige Endprodukt. Die Anzahl kannst du in deinem iterativen Planungsprozess natürlich anpassen.

Stelle einen groben Projektplan auf. Die Darstellung kann aus überlappenden Phasen bestehen, also eher altmodisch. Mit dem groben Plan verschaffst du dir einen Überblick, kannst dein Vorhaben besser vermitteln und die Projektlaufzeit besser einschätzen. Dein Projektplan kann beispielsweise die folgenden Phasen enthalten:

• Machbarkeitsstudie mit einem abschließenden Meilenstein “Go?”
• Blöcke für jeden Prototyp mit einer Dauer von 6-8 Wochen. Diese enthalten die Phasen Prozess-Analyse, Soll-Konzeption und Umsetzung und einen abschließenden Meilenstein “Vorstellung des Prototyps”.
• Funktionstests nach Fertigstellung von jedem Prototypen, parallel zum nächsten Prototyp
• Migrationstests, bspw. nach Fertigstellung des dritten Prototyps
• Integrationstest nach dem letzten Prototyp
• Schulung
• Cut-over und Go-Live
• Hypercare

Für jeden Prototyp definierst du die erforderlichen User Stories sowie die damit eingehenden Funktionen und Aufgabenpakete. Für den ersten Prototyp kannst du mit deinem Team die Aufgaben detailliert beschreiben. Für die nachfolgenden Prototyp zunächst auf einer etwas gröberen Ebene. Diese Aufgaben kannst du verfeinern, ergänzen oder sogar streichen, sobald der Prototyp gewachsen ist und entsprechende Erkenntnisse abgeleitet werden können. Vergleichbar mit dem Product Backlog im Scrum, welches niemals vollständig ist, sondern sich dynamisch verändert. Wenn du einen Puffer einplanen möchtest, ordnest du dem letzten Prototyp keine Aufgabenpakete zu. Alles was du nicht nach Plan schaffst, kannst du dann gedanklich in den letzten Prototyp schieben.

Die Anzahl an Prototypen ist definiert und du hast entsprechende Aufgaben zugeordnet. In vielen kleinen Workshops kann dein Team die Anforderungen aufnehmen, gemeinsam ein Soll-Konzept erarbeiten und dieses umsetzen. Das Ziel steht fest: der erste Prototyp soll in 6-8 Wochen fertig und vor allem lauffähig sein. Ein frühzeitig gesetzter Termin zur Präsentation des Prototyps kann dein Team motivieren, denn alle arbeiten auf ein gemeinsames Ziel hin. Zur Präsentation später mehr.

Je nach Team und Umgebung kannst du eher agiler oder klassischer agieren. Mir persönlich gefällt eine Mischform gut: mit einigen Personen stimmt man sich besser jeden Tag kurz ab, mit anderen hingegen besser einmal in der Woche, dafür dann länger. Wird eigentlich ein Lasten-/Pflichtenheft benötigt? Wie du möchtest bzw. was erforderlich ist. Aber bitte keine “save your ass” Mentalität. Viel wichtiger ist, dass die Dokumentation wächst und mit jeder Iteration aktualisiert wird. Auch hier gilt es, deinem Management die Vorteile der agilen Vorgehensweise aufzuzeigen. Was hilft die Umsetzung eines unterschriebenen Pflichtenheftes, wenn dein Kunde mit der Lösung später unzufrieden ist.

Nach 6-8 Wochen ist der erste Prototyp fertig. Vielleicht ist noch nicht alles enthalten, was du dir vorgenommen hast? Das ist nicht ganz so schlimm. Wichtiger ist, dass du deinen Prototypen präsentieren kannst. Er muss lauffähig sein.

Lade zur Prototyp-Präsentation alle interessierten und relevanten Stakeholder ein. Euer Publikum kann ruhig groß sein! Erkläre dann allerdings am Anfang der Präsentation geeignete Spielregeln. Beispielsweise wird aufgrund der vielen Teilnehmer die umfangreiche Diskussion auf kleinere Workshops in eigenen Terminen vertagt. Als ein geeignetes Tool empfehle ich dir ein Flipchart mit einem “Parkplatz” Symbol. Hier kannst du alle Themen sammeln, aber diese erst zum Schluss oder in eigenen Workshops behandeln.

Die Präsentation wird nicht von dir alleine gehalten, sondern von Repräsentanten des gesamten Teams. Ähnlich wie Tim Cook es bei den Apple Keynotes macht 😉 Schaffe Verständnis für das, was ein Prototyp darstellt. Werbe dafür, dass jeder frühzeitig einbezogen wird und aktiv mitgestaltet kann! Zum Schluss übergibst du den Prototyp zum Test in die Fachbereiche. In einem kurzen Lessons Learned Termin könnt Ihr im Team zudem über die letzten Wochen reflektieren und die Arbeit an dem nächsten Prototyp verbessern.