Agile SAP S/4HANA-Projekte mit SAP Activate

Seit dem ersten Aufkommen agiler Arbeitsweisen und der darauf aufbauenden agilen Frameworks Anfang der 2000er Jahre, erfreuen sich diese Methoden immer größerer Beliebtheit – und das gerade bei Softwareprojekten. Der früheste und gleichzeitig bekannteste Vertreter dieser Gattung ist das SCRUM-Vorgehensmodell.

Ist SAP Activate Agil oder Wasserfall – oder Beides?

Betrachten wir zunächst einmal die klassische und agile Vorgehensweise isoliert. Die Analyse von SAP-Projekte in der Vergangenheit identifizierte viele Aspekte, warum solche Projekte immer wieder scheiterten. Zu lange Laufzeiten mit ausgedehnten Blueprint-Phasen, zu wenig Transparenz, ein langläufiges  Risikolevel und explodierende Kosten waren einige dieser Punkte.

Warum sind Wasserfallprojekte starr und agile Projekte flexibel?

Im Projektspannungsfeld von Zielen, Zeit und Kosten werden bei klassischen Methoden wie dem Wasserfallmodell die Ziele – sprich „Einführung eines SAP-ERP-Systems für die Organisation XY“  – als fix gemanagt. Zeit und Kosten werden flexibel gesteuert.

Bei agilen Vorgehensmodellen hingegen sind Zeit und Kosten fix. Vielmehr werden Ziele als variables Gut betrachtet (s. Abbildung 1).

Auswirkungen der klassischen Projektmethode

Häufig sind Anforderungen, die zu Beginn des Projektes im sogenannten Blueprint erfasst wurden durch die verlängerte Projektlaufzeit bereits veraltet oder zumindest stark anpassungsbedürftig. Betrachtet man die Stabilität von Prozessen gegenüber notwendigen Veränderungen ist das wenig überraschend. Die Geschwindigkeit, mit der sich Prozesse ändern, wegfallen oder neue hinzukommen, hat sich in den letzten 30 bis 40 Jahren mehr als verdoppelt. Und damit haben wir hier schon einen ersten Kostentreiber.

Berücksichtigt das Projektteam diese geänderten Prozesse, steigen die Kosten durch längere Laufzeiten und die ggfs. notwendigen Anpassungen an die Software. Werden die Änderungen dagegen ignoriert, sinken Nutzen und Akzeptanz des Produktes, im schlimmsten Fall ist der zugrunde liegende Business Case überholt – das Projekt nicht mehr wirtschaftlich. Insofern besteht durchgehend ein hohes Risiko zum Scheitern meines Projekts bis zum Roll-Out.

Ist eine agile Projektumsetzung besser?

Eine rein agile Umsetzung eines SAP-Projektes kann komplex oder unmöglich werden, wenn Zeit und Kosten fix gehalten, die Produkt- respektive Prozessumfänge im Projekt aber aufgrund dieser Restriktionen gekürzt werden müssen. Gerade bei Ablösung eines alten ERP-Systems sind bereits bestehende Verträge gekündigt oder das Ende von Produktlebenszyklen absehbar. Somit sind die abzulösenden Prozesse mehr oder weniger fix.

Des Weiteren leben agile Methoden von Transparenz und einfacher, direkter Kommunikation. Das setzt eine in der Regel bereits agile Unternehmenskultur voraus, damit diese Aspekte gelebt und optimal eingesetzt werden. Viele Unternehmen befinden sich diesbezüglich noch am Anfang des Weges. Eine rein agile Umsetzung ist aus heutiger Sicht nicht realistisch.

Klassisch oder agil? SAP Activate vereint beide Vorgehensweisen

Gleich vorweg: Bei SAP Activate handelt es sich nicht um eine neue, eigene Projektmanagementmethode wie Prince2, V-Modell oder PMBook, sondern vielmehr um ein speziell auf SAP S/4HANA-Projekte zugeschnittenes Implementierungsverfahren.

SAP-Activate läuft in sechs aufeinander aufbauende Phasen ab: Discover, Prepare, Explore, Realize, Deploy und Run.

Das Nutzen der SAP Activate Methode bedingt bereits eine agilere Vorgehensweise gegenüber den klassischen Vorgehensweisen.

Kernkomponenten von SAP Activate sind die Best Practices, Guided Configurations und die Methodologie.

SAP Activate beschleunigt SAP S/4HANA-Projekte:

• Kein Wasserfall-Vorgehensmodell
• Keine aufwändige Blue-Print-Phase
• Schneller „Prototyp“ und Releases durch Best Practices mit Testskripten

Einführung in 6 aufeinander aufbauende Phasen unterteilt:

• Discover, Prepare, Explore, Realize, Deploy und Run

Das Produkt  ist nicht erst am Projektende releasefertig.

Somit ergibt sich schnell, ob Ziele und Kosten noch zu den ursprünglich geplanten Business Case passen. Je mehr Prozesse sich am Standard orientieren, desto schneller gibt es einen Nutzen in Form eines fertiggestellten, abgenommenen Prozesses.

Da die Key-User bereits zu einer frühen Phase im Projekt geschult wurden und aktiv am System mitarbeiten, erhöht dies die Prozesssicherheit; Fehler in der Prozessbearbeitung am System werden zum Projektstart reduziert. Der Lernkurveneffekt setzt früher ein.

Zwischenfazit: Klassisch oder agil? SAP Activate als optimale Vorgehensweise in SAP-Projekten

Die klassische Vorgehensweise in Projekten kann sich durch Starrheit negativ auf den Erfolg des Projekts auswirken, vor allem weil während des Projekts die nötige Transparenz fehlt. Hingegen sind reine agile Methoden mehr Utopie als Realität, weil durch die Komplexität des Projekt steigen kann, wenn Kosten und Zeit fix gehalten, aber gleichzeitig schnell Produkt- und/oder Prozessumfänge angepasst werden. SAP Activate als hybride Verbindung zwischen den beiden Vorgehensweisen beschleunigt die Arbeit in SAP-Projekten durch das Harmonisieren der jeweiligen Stärken. Je nach Grad der Berücksichtigung agiler Vorgehensweisen und Methoden können Potenziale gehoben werden. Dazu ist es nicht notwendig komplett nach SCRUM zu arbeiten, sondern die Integration agiler Elemente bedingt hier den Mehrwert. Aber selbst bei einer rein klassischen Umsetzung über V-Modell, Prince2 o. ä. behält das Implementierungsverfahren seine Stärken.

Zudem ist SAP-Activate durch den Einbau agiler Methoden auf Lieferebene (z. B. SCRUM) problemlos erweiterbar. Somit wird das Projekt wie bisher klassisch auf Projektmanagement- und Lenkungskreisebene gemanagt, aber der Fokus der Produktlieferung auf Projektteamebene gestärkt.

Wie kann ein hybrides Vorgehen mit SAP-Activate, sprich die Kombination von agilen und klassischen Methoden hilfreich sein? Wie sieht das in der Praxis aus?

Betrachten wir hierzu die drei Dimensionen Transparenz, Risiko und Nutzen:

Transparenz

Im klassischen Modell werden zu Beginn die Anforderungen in einer sog. Blueprint Phase mit dem Kunden erfasst. Daran schließt sich jedoch eine Phase der langen Intransparenz mit relativ wenig Kontakt zum Auftraggeber an. Die Berater nehmen das Customizing vor, Entwicklungsteams erstellen Formulare, Schnittstellen, zusätzliche Programme etc. Erst gegen Ende des Projektes sieht der Kunde das Ergebnis und die Transparenz steigt wieder (s. Abbildung 5 unten, blaue Kurve).

Im agilen Modell ist die Transparenz definitionsbedingt groß. In maximal zwei- bis vierwöchigen Sprints werden zuvor im Backlog definierte Anforderungen umgesetzt. Der Kunde sieht zu einem wesentlich früheren Zeitpunkt, wohin die Reise geht (s. Abbildung 5, graue Kurve).

SAP Activate schafft hier den Rahmen für eine höhere Transparenz (s. Abbildung 4, gelbe Kurve):  In den Phasen Prepare und Explore findet ein reger Austausch mit dem Kunden statt. In Absprache mit dem Auftraggeber entsteht eine Feature-Scope-List. Mit dieser als Basis können alle relevanten Best-Practice-Szenarien auf einem Testsystem installiert werden.

Die Key-User lernen über Schulungen am System, die mögliche spätere Lösung kennen. Durch die Schulungen sind alle in der Lage in den Fit2Standard-Workshops zu evaluieren, ob der Standard ausreichend ist oder angepasst werden soll.

Hier empfiehlt sich analog der agilen Vorgehensweise mit dem Berater Priorisierungen in Must-Have, Should-Have-, Nice-To-Have- oder Won‘t-Have-Anforderungen vorzunehmen. Diese Priorisierung ist wiederum Basis für die Ergänzung der Feature-Scope-List im Sinne eines Product-Backlog.

Die größte Übereinstimmung und Chance zur Nutzung agiler Methoden bietet sich dann in der sich anschließenden Realize-Phase (s. Abbildung 4).

Arbeite ich z. B. nach SCRUM in festen Teams und über einen Timebox von 2 bis 4 Wochen, so baue ich meine Sprint-Backlogs über den Product-Backlog auf. Durch die priorisierte Abarbeitung der Must-Haves entstehen nach jedem Sprint Increments und am Ende ein Minimum-Viable-Product (MVP).

Ist die Unternehmensorganisation meines Kunden noch nicht komplett agil ausgerichtet, bewähren sich in der Praxis die Einrichtung fester Projektwochentage, an denen die Teammitglieder an einem Ort zusammenkommen und die vordefinierte Umsetzung der Ziele aus dem Sprint-Backlog zu realisieren. Arbeitsergebnisse, Sprint-Backlogs und Projektfortschritt sollten unbedingt auf einem für alle Projektmitglieder zugänglichen Collaboration-Tool (z. B. Sharepoint, besser ein Projektboard) publiziert werden.

Risiko & Nutzen

Einhergehend mit der erst späten Produktbereitstellung verbleibt im klassischen Fall lange ein hohes Risikoniveau. Erst gegen Ende des Projektes ist sichtbar, ob das Produkt den geschäftlichen Nutzen liefert (s. Abbildung 5, blaue Kurven)

Im agilen Umfeld ist der Einblick zu einem früheren Zeitpunkt da. Zum einen besteht die Möglichkeit eines „fast-to-fail“: Der geschäftliche Nutzen bleibt unter den Erwartungen. Durch die Transparenz ist das allerdings früher erkennbar und das Projekt kann kostengünstiger beendet werden. Zum anderen ergeben sich Möglichkeiten durch Kundenfeedbacks notwendige Anpassungen früher zu identifizieren und zu berücksichtigen. Zusätzlich erhält der Auftraggeber durch die Lieferung von Inkrementen früher ein einsatzfähiges Produkt. Das Projekt erfährt früher einen messbaren Nutzen (s. Abbildung 5, grau Kurven).

SAP Activate agiert auch hier in der Mitte zwischen beiden Vorgehensweisen (s. Abbildung 5: orange Kurve).

Bereits zu Beginn des Projektes erhält der Auftraggeber über Best-Practices ein Produkt und Testsystem. Die Teammitglieder können an diesem System mit Hilfe der sog. Fit2-Standard-Workshops einen ersten Einblick bekommen. So ergeben sich bereits in der Phase Explore folgende Ergebnisse:

• Fall 1: Die von SAP ausgelieferten Prozesse müssen nicht angepasst werden. Durch die Guided Configuration werden diese Prozesse schnell lauf- und einsatzfähig. Die mitgelieferten Testskripts beschleunigen die fachlichen Tests.
• Fall 2: Die von SAP ausgelieferten Prozesse müssen an die Organisation des Kunden angepasst werden. Umfang und Aufwand der Anpassung sind aber bekannt und lassen sich evaluieren.

Somit ergibt sich schnell, ob Ziele und Kosten noch zu den ursprünglich geplanten Business Case passen. Je mehr Prozesse sich am Standard orientieren, desto schneller gibt es einen Nutzen in Form eines fertiggestellten, abgenommenen Prozesses.

Da die Key-User bereits zu einer frühen Phase im Projekt geschult wurden und aktiv am System mitarbeiten, erhöht dies die Prozesssicherheit; Fehler in der Prozessbearbeitung am System werden zum Projektstart reduziert. Der Lernkurveneffekt setzt früher ein.

Fazit: SAP Activate beschleunigt mit agilen Ansätzen SAP S/4HANA-Projekte

Die klassische Vorgehensweise in Projekten kann sich durch Starrheit negativ auf den Erfolg des Projekts auswirken, vor allem weil während des Projekts die nötige Transparenz fehlt. Hingegen sind reine agile Methoden im Hinblick auf eine SAP-Implementierung aus heutiger Sicht nicht realistisch, weil die Komplexität des Projekt steigen kann, wenn Kosten und Zeit fix gehalten, aber gleichzeitig schnell Produkt- und/oder Prozessumfänge angepasst werden müssen. SAP Activate als hybride Verbindung zwischen den beiden Vorgehensweisen beschleunigt die Arbeit in SAP-Projekten durch das Harmonisieren der jeweiligen Stärken. Je nach Grad der Berücksichtigung agiler Vorgehensweisen und Methoden können Potenziale gehoben werden. Dazu ist es nicht notwendig komplett nach SCRUM zu arbeiten, sondern die Integration agiler Elemente bedingt hier den Mehrwert. Aber selbst bei einer rein klassischen Umsetzung über V-Modell, Prince2 o. ä. behält das Implementierungsverfahren seine Stärken.

Das könnte Sie auch interessieren: 

Alles zur Product vs. Contract Conversion Ihres SAP-Lizenzvertrags.

Wie Sie Ihren eigenen Weg zu SAP S/4HANA nehmen – mit individuellerKonzeption einer ERP-Lösung