Martin Kipka - SAP Activate - Agilität in SAP S/4HANA-Implementierungsprojekten

Business Processes: Neben der Tatsache, dass die Standardsoftware selbst einiges an Content enthält, werden seitens der SAP über den Best Practice Explorer (vgl. Abschnitt 11.2bzw. https://rapid.sap.com/bp/) Pakete bereitgestellt, die im Rahmen einer S/4HANA-Implementierung sehr schnell zu einem funktionsfähigen Standardsystem führen. Diese Pakete bilden die Grundlage für vorkonfigurierte Systeme und bündeln die Erfahrung der SAP aus vielen Implementierungsprojekten. Die Kunden entscheiden jeweils anhand ihrer Projektziele, ob und welche Pakete sie verwenden möchten. Außerdem gehören sogenannte Ready-to-run-Systeme dazu. Hierbei handelt es sich um diverse Systeme, die sofort als Grundlage für ein Implementierungsprojekt verwendet werden können. Meistens dienen sie als Trial-Version (Model Company) dazu, das System und seine Oberfläche erst einmal kennenzulernen.

Project Library: Neben Beispielprojektplänen stellt die SAP im Rahmen von SAP Activate eine große Anzahl von Beschleunigern über das Internet bereit. Das können Testskripte, Foliensätze, Whitepapers, Exceltabellen und vieles mehr sein. Ich gehe in Kapitel 11gesondert darauf ein.

Integration and Migration: Zur Integration und Migration liefert SAP einerseits Content, anderseits aber auch Hilfestellung in Form von Anleitungen aus.

Ein Tool kann eine bestimmte Funktion innerhalb des SAP-S/4HANA-Systems oder auch eine »Standalone«-Lösung in Gestalt eines Non-SAP-S/4HANA-Systems, eines Online-Portals oder in anderer Form sein. Insofern bilden Tools einen Teil der Projektinfrastruktur. Sie erlauben den Zugriff auf und das Verwalten von projektrelevanten Informationen. Manche Tools werden über das Internet bereitgestellt und können intuitiv sofort genutzt werden. Andere sind umfangreicher und bedürfen ggf. eines eigenen Projekts mit genügend Zeit zum Kennenlernen des Tools (z.B. SAP Solution Manager). Einige dieser Tools erfordern ggf. sogar eigene Lizenzen.

Je nach Umfang kann der Nutzen eines Tools ganz unterschiedlich sein, indem entweder nur ein Teil des Projektteams oder aber das gesamte Projekt davon profitiert. SAP unterscheidet folgende Tools:

Process Automation: Hierzu gehört z.B. das Bereitstellen einer Plattform zur Durchführung der projektbezogenen Prozesse. Das Projektteam erstellt und verwaltet die projektbezogenen Daten.

Content Provisioning: Hierunter versteht SAP die Bereitstellung von Content für das Konfigurieren (z.B. Wizards, die die SAP als »Guided Configuration« bezeichnet und im Rahmen von Cloud-Implementierungen einsetzt) und den Betrieb von Lösungen, aber auch Content für das Durchführen von Trainings (z.B. Learning Hub).

Dies ist sicherlich das Kernelement der Neuerungen im Rahmen von S/4HANA-Implementierungen. Wie bereits im Vorwort erwähnt, greift die SAP in der Projektmethodik für eine Vielzahl von Projekten jetzt auch agile Elemente auf. Diese agilen Momente innerhalb der Activate-Methodik orientieren sich stark an den Vorgaben des Project Management Institute (PMI). Die SAP gliedert die Methode nach vier Begriffen:

Die neue Methodik sieht vier Kernprojektphasen sowie eine vor- und eine nachgelagerte Phase vor (siehe Abbildung 2.2). Wer sich ein wenig mit Projektvorgehensmodellen beschäftigt, erkennt unschwer an der Abbildung und an ihren Begriffen (z.B. Fit-to-Standard-Analyse, Sprint), dass insbesondere die Phasen »Explore« und »Realize« agile Elemente zur Activate-Methodik beitragen. Während Projekte nach dem Wasserfall-Prinzip sequenziell voranschreiten (jede Stufe des Wasserfalls beschreibt eine Phase), sind agile Projekte inkrementell angelegt, was bedeutet, dass Verbesserungen in kleinen Schritten kontinuierlich verfolgt werden.

Abbildung 2.2: Phasen des SAP-Activate-Vorgehensmodells

Falls Sie jetzt bereits neugierig sind, können Sie schon mal im Abschnitt 5.1lesen, welche Unterschiede zwischen agilem Projektvorgehen und den bisher für Implementierungsprojekte üblichen wasserfallbasierten Methoden bestehen.

Diejenigen Leser, die bisher beispielsweise schon mit Accelerated SAP (kurz ASAP) bzw. daran angelehnten Vorgehensmodellen vertraut waren (Wasserfall), werden in der Abbildung 2.2 die sehr wichtige Blueprint-Phase vermissen. Immerhin wurden während dieser Phase die wichtigen Fachkonzepte, Pflichtenhefte oder Sollkonzepte geschrieben, die insbesondere für das gemeinsame Verständnis der zu erbringenden Projektleistungen von erheblicher Bedeutung waren. Gelegentlich – und so etwas soll ja vorgekommen sein – wurden dann sogenannte Change Requests (CR) erforderlich, weil die Realität den verfassten Plan »überholt« hatte.

Für SAP Activate gilt: Es gibt nach wie vor einen wasserfallbasierten Ansatz – wenigstens für On-Premise-Installationen. Ansonsten bevorzugt SAP eindeutig das agile Vorgehen.

Ein Workstream umfasst einen Bereich des Projekts, der einer eigenständigen Steuerung bedarf. Häufig wird ein Workstream durch ein Team besetzt, das die Aufgaben übernimmt.

Deliverables sind die erwarteten Ergebnisse, die man in Tasks, also dedizierte Aufgaben, gliedert, um das Projekt möglichst effizient zu gestalten.

Die meisten Projekttätigkeiten basieren auf als Artifacts bezeichneten Dokumenten oder Informationen, bzw. generieren solche.

Wie bereits in der Einleitung erwähnt, unterliegen Projekte regelmäßig einigen Zielkonflikten. Die grundlegenden Zielkonflikte ergeben sich aus dem magischen Projektdreieck (siehe Abbildung 2.3).

Qualität, Zeit und Budget, die drei kritischen Erfolgsfaktoren in Projekten, müssen seitens des Projektmanagements so kombiniert werden, dass der Projekterfolg sichergestellt wird. Es geht also fast immer darum, ein Projekt »on time, on budget and on quality« zu liefern. Dabei stellt sich schnell heraus:

Die Zeit ist knapp – und wird im Projektverlauf scheinbar immer knapper.

Das Budget ist niedrig – und verbraucht sich zunehmend schnell.

Der Qualitätsanspruch ist hoch – und steigt im Projektverlauf.

Abbildung 2.3: Zielkonflikte im magischen Projektdreieck

Im Vergleich traditioneller Vorgehensmodelle mit dem magischen Projektdreieck in SAP Activate zeigt sich, dass es zwar in beiden Fällen darum geht, diese Zielkonflikte möglichst optimal aufzulösen. Worin sie sich allerdings konkret unterscheiden, möchte ich anhand des jeweiligen Projektdreiecks kurz darstellen.

In Abbildung 2.3 beschreibt die Grundfläche des Dreiecks den Projektumfang, wobei jedes kleine Dreieck symbolisch für eine gewünschte Teilleistung des Projekts steht. Die Summe der Teilleistungen ergibt den Umfang des Gesamtprojekts, und dieser wird im traditionellen Ansatz im Lasten- oder Pflichtenheft beschrieben. Im Zusammenhang mit SAP-Implementierungen wurde hierbei gemäß dem älteren Vorgehensmodell accelerated SAP (ASAP) gerne vom Business Blueprint gesprochen. Wird nun eine zusätzliche Leistung gewünscht oder ist sie aufgrund neuer Gegebenheiten erforderlich, so wird schnell deutlich, dass diese nicht mehr in die bereits komplett beschriebene Grundfläche passt. Damit muss die Fläche zwangsläufig angepasst werden. Dies wirkt sich dann auf mindestens zwei, manchmal auf alle drei Ziele aus (siehe Abbildung 2.4).