SAP Activate - Agilität in SAP S/4HANA-Implementierungsprojekten. Martin Kipka
Читать онлайн книгу.
Tools
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).
2.1.3 Methodology
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:
1. Phasen:
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.1 lesen, 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.
2. Workstream:
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.
3. Deliverables and Tasks:
Deliverables sind die erwarteten Ergebnisse, die man in Tasks, also dedizierte Aufgaben, gliedert, um das Projekt möglichst effizient zu gestalten.
4. Artifacts:
Die meisten Projekttätigkeiten basieren auf als Artifacts bezeichneten Dokumenten oder Informationen, bzw. generieren solche.
2.2 Die kritischen Erfolgsfaktoren in Projekten
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).
Abbildung 2.4: Change im traditionellen Projektvorgehensmodell
Im Ergebnis bedeutet dies, dass der Change-Request-Prozess die Frage nach dem neuen Umfang des Gesamtprojekts mit Blick auf Zeit, Geld und Qualität beantworten muss.
Change Requests haben typische Ursachen wie etwa:
Der Kunde lernt im Verlauf des Projekts die Möglichkeiten der Standardsoftware immer besser kennen und verstehen und möchte die gewonnenen Erkenntnisse dann auch in seinem System nutzen.
Die Berater und Programmierer verstehen das Geschäftsmodell im Laufe der Zeit immer besser und versuchen, ihre Erkenntnisse entsprechend im System umzusetzen.
Das Projekt wurde ausgeschrieben. Der Implementierungspartner hat das Projekt mit dem Ziel eines Zuschlags jedoch sehr knapp kalkuliert, sodass es keine Reserven gibt.
Missverständnisse im Lasten- oder Pflichtenheft werden erst spät im Projektverlauf erkannt.
Unstimmigkeiten zwischen Implementierungspartner und Kunde schwelen lange unter der Oberfläche und eskalieren mit zunehmendem Termindruck.
Der Fachbereich wird zu spät mit den