SAP wird gerne als Standardsoftware bezeichnet. Also als Software, die zu einem Anwendungsgebiet für den anonymen Markt erstellt wird – und mittels „Customizing“ an die speziellen Benutzeranforderungen angepasst oder sogar auf die gesamte betriebliche Ablauforganisation ausgerichtet werden muss. Aber wie flexibel und anpassungsfähig ist SAP als Standardsoftware? Gibt es Restriktionen, die z. B. das Erschaffen von „potentiell auslieferbaren Inkrementen“ am Ende eines Sprints einschränken? Ist die Konzeption im klassischen Umfang notwendig oder kann sie iterativ erfolgen? Kurz: Wie agil geht SAP?
Agilon hat 2019 eine Umfrage zu agilen Arbeitsweisen in SAP-Projekten durchgeführt und folgende drei Erkenntnisse festgehalten:
- Agile Ansätze sind mittlerweile führend bei SAP-Projekten (55 %)<
- Agiles Potential wird aber noch nicht ausgeschöpft
- Haupthindernisse dabei: Hybridisierung von Agil und Wasserfall, sowie Nichteinhaltung „agiler Spielregeln“
Es gibt sogar eine SAP-eigene agile Methodik „SAP Activate“, die in zwölf Prozent der Fälle (Platz 2 hinter Scrum) eingesetzt wurde. Zugleich gibt es in Unternehmen, die SAP nutzen, immer noch Unkenntnis bezüglich der Flexibilität und Anpassungsfähigkeit. Als langjähriger IT-Dienstleister möchten wir gerne unsere Erfahrungen aus zahlreichen SAP-Projekten mit Ihnen teilen.
Von Individual-Entwicklung bis Customizing – Kundenwünsche geben den Weg vor
Entwicklungsleistungen in einem SAP-Projekt schließen in der Regel auch Erweiterungen an der Standardsoftware und Individual-Entwicklungen mit ein. In vielen Anwendungsfällen muss aber nicht unbedingt entwickelt werden, denn beim Customizing wird die bestehende Software eigentlich „nur“ so konfiguriert, dass sie funktioniert, wie es im Projekt gewünscht ist. SAP Netweaver kann aber auch als reine Entwicklungsplattform verwendet werden.
Unterschiedliche Herangehensweisen führen zum Ziel
Wie in allen Projekten, sind SAP-Projekte bzw. deren Herangehensweisen nicht immer gleich: Der Kontext und die Tragweite bei SAP ist ein bisschen größer, deshalb sind kleinere Inkremente z. T. weniger sinnvoll. Darüber hinaus sind nur kleinere Elemente testbar und komplexere Tests bislang nur schwer automatisierbar. Bei Kundenindividuellen SAP-Entwicklungen werden hingegen Pakete sogar künstlich etwas kleiner geschnitten.
Das Entwickeln ist hier ähnlich wie bei Individualsoftware. Allerdings können nicht mehrere Entwickler*innen gleichzeitig an demselben Source Code arbeiten. Hier schafft zukünftig ABAP in der Cloud Abhilfe, jedoch lassen sich nicht alle Individualentwicklungen funktionell eins zu eins in die Cloud überführen. Die Anpassungsmöglichkeiten der Software sind in der ABAP Cloud begrenzt.
Es gibt auch Projekte, in denen Inkremente in Releases zusammengefasst live gehen. Bis zum Sprint Review werden die Features auf der Integrationsumgebung eingespielt und getestet. Die Anzahl der Sprints bis zum Release variiert von minimal drei Sprints bis vier Monate. Besonders an SAP ist, dass nicht eine Komplettsoftware versioniert wird, sondern nur Teile davon. So können Teile ausgeliefert werden, auch wenn in angrenzenden Teilen etwas angepasst wird. Große SAP-Releases mit Funktionsupdates ziehen viele Anpassungen und Nacharbeiten mit sich. In derSAP S/4HANA Cloud wird alle drei Monate ein neues Release ausgeliefert, welches Individualentwicklungen auf ein Minimum beschränkt.
Automatisierte Tests sind daher umso notwendiger und könnten bspw. über SAP iRPA durchgeführt werden. Es gibt SAP-Projekte, die in der Entwicklung zwar iterativ, gesamthaft aber nach Wasserfall organisiert sind. Etwa bei der Ablösung eines Altsystems, wozu eine Datenmigration und Weiterentwicklungen notwendig sind. Für die Datenmigration gibt es eine lange Planungsphase, in der das Vorhaben aber iterativ mit den Kunden besprochen wird.
In solchen Fällen werden gezielt Testmigrationen durchgeführt, bevor die Entwicklungsumfänge live gesetzt werden. Durch diese Migrationen kann das Team iterativ herausfinden, was nach der Datenmigration vom Altsystem ins neue System bereits funktioniert bzw. was nicht und Erkenntnisse daraus in die zukünftige Individualentwicklung einfließen lassen. Im letzten Schritt wird hier auch der Go Live simuliert. Fließt zusätzlich eine Form von Key User Feedback ein, ergibt sich hier eine sichere und auch ansatzweise agile Methodik. Naturgemäß gibt es in SAP sehr viele Schnittstellen, die auch dokumentiert werden müssen. Hierfür sind revisionssichere und freigegebene Fach- und IT-Konzepte unerlässlich.
Fehlende bzw. langwierige Freigaben sind in SAP-Projekten nicht selten ein Blocker. Hilfreich im Product Backlog ist manchmal auch eine Unterscheidung nach mehreren Arten von Stories: Entwicklungsleistungen, konzeptionelle Stories und Unterstützungsleistungen (z. B. Tests). Die konzeptionellen Stories dienen zum kontinuierlichen Ausbau des Product Backlogs. Das heißt: Aus einer konzeptionellen Story wird dann eine Entwicklerstory. Diese Vorgehensweise ermöglicht eine iterative fachliche Detailierung und somit eine frühere Wertschöpfung als in klassischen Vorgehensweisen.
Spezifische system- und betriebswirtschaftliche Kenntnisse unverzichtbar
Das agile Team sollte immer über alle notwendigen Kenntnisse verfügen, die es zur Umsetzung der Inhalte des Product Backlog benötigt. Im Falle SAP sind es spezifische system- und betriebswirtschaftliche Prozesskenntnisse. In größeren Projekten ist der Beratungsanteil oftmals hoch, so dass teils mehrere Business Analysten im Team sind. Obwohl Scrum keine Rollen und Spezialisten vorsieht, gibt es in SAP-Projekten Spezialisten, doch diese sollten idealerweise über crossfunktionale Kenntnisse verfügen – und als beratende Entwickler*innen bzw. entwickelnde Berater*innen agieren.
Aufgrund der Komplexität eines SAP ERP Systems kaufen Kunden fast ausschließlich Beratungsleistungen ein, um die Rolle des Product Owners zu unterstützen. Manchmal werden diese Leistungen durch einen Support ergänzt, der zunehmend in ein DevOps Modell integriert wird.
Fazit: SAP und Agil – das geht!
Eine der größten Herausforderungen ist, dass sich SAP ERP System im Vergleich zu anderen Systemen wie ein Faden durch das gesamte Unternehmen zieht und deshalb auch eine kontinuierliche Verfügbarkeit des Systems mit seinen Funktionalitäten gewährleistet werden muss. Das hat zu Folge, dass gegebenenfalls Freigaben den Fortschritt etwas zügeln können.
Ansätze wie iteratives Vorgehen, Test-Migrationen, Key User Feedback, sprintweise Konzeptionen und DevOps-Modelle zeigen, dass es immer einen agilen Weg gibt – ganz gleich wie die Anforderung ist. Das bestätigt auch die oben genannte Studie und widerlegt damit das verstaubte Vorurteil des Wasserfall-Must-Have. Die Mehrheit der SAP-Projekte weist eine Hybridisierung des agilen und klassischen Ansatzes auf. Ob dies der beste oder eher der „vorsichtige“ Weg in Richtung „Agilisierung“ von SAP-Projekten ist, wird sich noch zeigen.
Erfahren Sie mehr über unsere innovativen Services im SAP-Bereich – in der SAP Success Story.
Sie möchten mehr über Agile Methoden erfahren?
Unser Expertenteam berät Sie gerne.
