TEIL I. IST EIN AGILER ANSATZ FÜR EIN SAP-PROJEKT ANWENDBAR? SOLLTE ER GEGENÜBER DEM KLASSISCHEN WASSERFALLMODELL BEVORZUGT WERDEN?

Warum AGIL?

Laut der Umfrage „9. Global Project Management Survey “ (2017) des Project Management Institute (PMI) wird ein erheblicher Teil der IT-Projekte weltweit immer noch verspätet abgeschlossen (49%), werden Budgets überschritten (43%), ursprüngliche Ziele verfehlt  (31%) bzw. scheitern Projekte komplett (14%). Hauptgründe für das Scheitern sind unklare bzw. unrealistische Projektziele (37%) und eine schlechte Kommunikation (19%).

Abbildung 1: Erfolgsraten von IT-Projekten, Quelle: PMI pulse of profession 2017

Im Vergleich zu ihren früheren Umfragen zeichnete sich jedoch ein positiver Trend ab. Zum ersten Mal seit fünf Jahren erfüllen mehr Projekte ihre Ziele und es gab auch einen deutlichen Rückgang der Verluste: Unternehmen verschwenden durchschnittlich 97 Millionen US-Dollar für jede investierte Milliarde US-Dollar aufgrund schlechter Projektleistung – das ist ein Rückgang von 20 Prozent gegenüber dem Vorjahr.

Die Studie legt nahe, dass dieser positive Trend auf eine veränderte Art und Weise zurückzuführen ist, wie Organisationen ihre Projekte und Programme aufsetzen. Ein bemerkenswerter Wandel war die wachsende Bedeutung und Anwendung von Agilität als Technik für die Durchführung von Projekten. 71% der Unternehmen geben an, manchmal, oft oder immer agile Ansätze für ihre Projekte zu verwenden. Rund 72% aller Umfrageteilnehmer gaben an, dass die organisatorische Agilität in ihrer Organisation in den letzten fünf Jahren gestiegen ist. Darüber hinaus wurde festgestellt, dass die „Champions“ (Organisationen, bei denen 80% oder mehr der Projekte erfolgreich abgeschlossen wurden) einen starken Fokus auf agile Projektansätze legen – 55 Prozent gegenüber 24 Prozent der ‚Underperformer‘.

Abbildung 2: Änderung der organisatorischen Agilität im Laufe der Zeit, Quelle: PMI pulse of profession 2017

Abbildung 3: Aktuelle Verwendung agiler Ansätze, Quelle: PMI pulse of profession 2017

Angesichts dieser Trends lohnt es sich über agile Ansätze auch im Rahmen von SAP-Projekten nachzudenken.

Was ist ein agiler Ansatz?

Derzeit gibt es viele Definitionen für Agilität. In unserer Definition ziehen wir es vor, zu den „Wurzeln“ zurückzukehren:
Ein agiler Ansatz ist eine Arbeitsweise gemäß dem Manifest für Agile Softwareentwicklung auf der Grundlage der

agilen Werte*:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge,
• Funktionierende Software mehr als umfassende Dokumentation,
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung,
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

und agilen Prinzipien**:

• Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen,
• Anforderungsänderungen selbst spät in der Entwicklung willkommen zu heißen,
• funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate zu liefern,
• Enge, tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes,
• Projekte rund um motivierte Individuen aufsetzen, denen vertraut wird
• Persönliche Gespräche sind die beste Form der Kommunikation (Co-Location).
• Funktionierende Software als wichtigstes Fortschrittsmaß,
• Nachhaltige Entwicklung mit einem konstanten Tempo,
• Kontinuierlicher Fokus für technische Exzellenz und gutes Design,
• Einfachheit ist essenziell,
• Die besten Architekturen, Anforderungen und Designs werden von selbstorganisierten Teams erstellt,
• Das Team überlegt regelmäßig, wie es effektiver werden kann, und passt sich entsprechend an.

Quellen:
* Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). „Manifesto for Agile Software Development„. Agile Alliance. Retrieved 14 June 2010.
** Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). „Principles behind the Agile Manifesto„. Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.

Nachfolgend brechen wir diese Werte und Prinzipien in Projektpraktiken herunter, indem wir ein agiles SAP-Projekt mit einem Wasserfall-SAP-Projekt vergleichen.

Abbildung 4: Merkmale von Wasserfall- und agilen SAP-Projekten, Quelle: Agilon GmbH

Im Fokus eines agilen SAP-Projekts stehen der Kunde und seine Anforderungen. Die Anforderungen des Kunden werden von den Projekt-Stakeholdern in Projektziele „übersetzt“, die vom Produkt- / Prozessverantwortlichen (engl. Product Owner) in priorisierte Funktionalitäten heruntergebrochen werden. Teams bilden sich um diese Funktionalitäten (engl. features), sodass jede Funktionalität von einem Team durchgehend  implementiert werden kann. Die Implementierung der Funktionalitäten ist ein iterativer und inkrementeller Prozess. Jede Iteration umfasst Planungs-, Design-, Entwicklungs- und Testaktivitäten für priorisierte Funktionalitäten. Am Ende jeder Iteration demonstrieren die Teams den Projekt-Stakeholdern und anderen Teams die Ergebnisse und reflektieren ihre Fortschritte. Vor der nächsten Iteration überprüft, passt und priorisiert der Product Owner die Anforderungen neu, sodass Anforderungsänderungen im Gegensatz zu Wasserfall-SAP-Projekten nicht auf das Projektende verschoben werden. Da den Teams vertraut wird, dass sie ihr Bestes geben und sich kontinuierlich verbessern, gibt es keine Autoritätsrolle, die dafür verantwortlich ist, die Teams zu verwalten und ihre Arbeit zu planen. Die regelmäßig vorgestellte Systemdemo und das Feedback der Kunden und Projekt-Stakeholder sind die einzige formale Messgröße für den Projektfortschritt.

Ist Agilität auf SAP-Projekte anwendbar?

Um diese Frage zu beantworten, stützen wir uns auf die Anleitung der bekannten „Stacey Matrix“, die von Ralph Douglas Stacey, Professor für Management an der Hertfordshire Business School in Großbritannien, entwickelt wurde.

Die „Stacey Matrix“ ist ein Modell für die Bewältigung komplexer Situationen. Sie zeigt die Gewissheit darüber, WAS zu tun ist auf der vertikalen Achse, und die Gewissheit darüber, WIE es zu tun ist auf der horizontalen Achse. Je nachdem, wo auf der Matrix eine Aufgabe oder eine Initiative landet, wird sie einer der Entscheidungsdomänen zugeordnet – einfach / offensichtlich, kompliziert, komplex oder chaotisch. Für jede Domäne gibt es einen empfohlenen Entscheidungsansatz:

Abbildung 5: Stacey Matrix, adaptiert von R. D. Stacey, Quelle: The Tools and Techniques of Leadership and Management: Meeting the challenge of complexity. Routledge, London 2012.

Diese Entscheidungsrichtlinien ordnen wir agilen und nicht agilen Prinzipien und Praktiken zu und schlussfolgern, dass agile Ansätze eher für die Domänen „Kompliziert“, „Komplex“ und „Chaotisch“ geeignet sind. Nicht agile Ansätze eignen sich dagegen eher für die Domäne „Einfach“.

Abbildung 6: Entscheidungsfindung in Wasserfall- und agilen Frameworks, Quelle: Agilon GmbH

Im nächsten Schritt werden wir untersuchen, welchen Domänen SAP-Projekte zugeordnet werden können. Klären wir zunächst, was ein SAP-Projekt ist.

Ein SAP-Projekt im weiteren Sinne ist ein IT-Projekt, das auf die Implementierung oder Upgrade eines oder mehrerer SAP-Produkte in einer Organisation zum Zweck der Prozessautomatisierung oder -optimierung abzielt. SAP-Produkte sind Unternehmenssoftware, Plattformen und Frameworks der Firma SAP SE.

Ein SAP-Projekt im engeren Sinne ist ein Projekt, das einem der folgenden Zwecke dient:

• SAP-Implementierung (IML): Ziel ist es, entweder manuelle Prozesse eines Unternehmens mithilfe von SAP-Produkten zu automatisieren / zu digitalisieren oder ältere Unternehmenssoftware durch SAP-Produkte ganz oder teilweise zu ersetzen.
• SAP Landscape Transformation (LST): Ziel ist es, die aktuelle SAP-Systemlandschaft aufgrund von Reorganisationen, Fusionen und Übernahmen, Ausgliederungen, Prozess- und Kostenineffizienzen usw. an das sich ändernde Geschäftsumfeld anzupassen.
• SAP Upgrade (UPG): Ziel ist es, eine ältere SAP-Produktversion auf eine neuere zu aktualisieren, häufig begleitet von prozessualen und organisatorischen Anpassungen der neuen technischen Funktionen und Anforderungen.
• SAP Improvements (IMR): Ziel ist es, die vorhandenen Prozesse und / oder Anwendungen zu verbessern.
• SAP Support (SUP): Ziel ist es, SAP-Benutzer bei der Analyse und Behebung technischer oder funktionaler Probleme zu unterstützen.

Jeder Projekttyp kann mit einem bestimmten Maß an Gewissheit für das „Was“ (Anforderungen) und das „Wie“ (Lösung zur Erfüllung der Anforderungen) verknüpft werden.

Abbildung 7: SAP-Projekttypen nach Komplexität, Quelle: Agilon GmbH

Darüber hinaus variieren SAP-Projekte in ihrer Größe und jeder Projekttyp kann klein, mittel oder groß sein. Dies ist z.B. abhängig von der Anzahl der zu implementierenden Module, Entwicklungen und Schnittstellen, der Anzahl der Buchungskreise, der zu schulenden Benutzer usw. Hier eine beispielhafte Größenschätzung:

Abbildung 8: SAP-Projekttypen nach Projektgröße, Quelle: Agilon GmbH

Je größer das Projekt ist, desto höher ist natürlich die Anzahl der technischen, prozessualen und organisatorischen Abhängigkeiten und desto geringer ist die Gewissheit über die zu implementierenden Geschäftsanforderungen und -lösungen.

Unter Berücksichtigung all dieser Punkte können die meisten SAP-Projekte entweder der Domäne „Kompliziert“ oder „Komplex“ in der „Stacey-Matrix“ zugeordnet werden. Ausnahmen bilden Support- / Bugfixing-Projekte, kleine Verbesserungen und kleine System-Upgrades.

Unser Brainstorming in einer Runde erfahrener SAP-Experten hat bestätigt, dass nahezu alle SAP-Projekte durch hohe Unsicherheit, hohe Komplexität, viele Abhängigkeiten, lange Dauer und hohe Expertise gekennzeichnet sind.

Da der vorteilhafteste Ansatz für die Domänen „Kompliziert“ oder „Komplex“ ein agiler Ansatz ist, empfehlen wir diesen Ansatz für komplexe und komplizierte SAP-Projekte, inbs. für neue SAP-Implementierungen, Transformationen der SAP-Systemlandschaft, große SAP-Upgrades, große und mittelgroße Verbesserungsprojekte.

Was sind Vor- und Nachteile eines agilen Ansatzes im Kontext von SAP-Projekten?

Nachfolgend schauen wir uns näher typische Probleme von SAP-Projekten an, um herauszufinden, ob ein agiler Ansatz helfen kann, diese zu überwinden.

Abbildung 9: Vor- und Nachteile eines agilen Ansatzes in Bezug auf die typischen SAP-Projektprobleme, Quelle: Agilon GmbH

Ein agiler Ansatz bildet die Grundlage für die Überwindung vieler typischer SAP-Projektprobleme. Er verbessert die Kommunikation zwischen Business- und IT-Experten, Anwendern, Beratern und Entwicklern innerhalb eines Teams sowie zwischen Teams und Projekt-Stakeholdern. Bestimmt durch Wertorientierung hilft er, unnötige Dokumentationen zu vermeiden und den Wert der implementierten Software zu steigern. Fortlaufende Teambesprechungen mit dem Product Owner stellen sicher, dass die Anforderungen vollständig verstanden werden und entsprechend ihrer Priorität geplant und umgesetzt werden.

Ein agiler Ansatz schafft ein Arbeitsumfeld, das kontinuierliches schnelles Lernen, Wissensaustausch und Begeisterung der beteiligten Personen fördert. Infolgedessen steigen Expertise und Enthusiasmus der Projektbeteiligten.

Im Gegensatz zum Wasserfall-Ansatz mit festem Umfang und variabler Zeit und variablem Budget legt ein agiler Ansatz Zeitrahmen fest und ermöglicht, dass der Projektumfang abhängig vom Wertbeitrag und den Prioritäten variiert. Dies verhindert Kostenfallen und Verzögerungen und stellt sicher, dass die richtigen wertorientierten Ergebnisse erzielt werden.

Ein agiler Ansatz hat jedoch auch seine Grenzen. Wenn Werte nicht klar definiert und kommuniziert werden, es keine konsistente Priorisierung der Ziele und Anforderungen gibt oder agile Werte und Prinzipien in der Organisation nicht gelebt werden, können agile Projekte zu Budgetüberschreitungen und Gesamtversagen führen, ähnlich wie bei nicht agilen Projekten.