erhalten die Kunden Updates, Fehlerbereinigungen werden im Allgemeinen innerhalb von zwei Wochen bei jedem Kunden eingespielt. Alle Kunden einer Serverumgebung sind in diesem Fall auf dem gleichen Release- und Patchlevel, haben also hinsichtlich der Aktualisierungen denselben Stand. Kunden, die sich für die S/4HANA MTE entscheiden, sollten also im Sinne von Abbildung 1.2 bereit sein, sich durch Anpassung von Aufbau- und Ablauforganisation dem SAP-Standard anzunähern. Trifft dieses Szenario für Ihr Unternehmen zu, ist Abschnitt 7.6 von besonderer Relevanz.
S/4HANA Cloud Single Tenant Edition (S/4HANA STE): Hierbei handelt es sich im Grunde um ein S/4HANA-On-Premise-System, das auf der SAP HANA Enterprise Cloud (HEC) ausgerollt wird und nicht den Release-Zyklen von S/4HANA MTE unterworfen ist. Damit stehen dem Kunden sowohl der gesamte Systemumfang, der n-Premise angeboten wird, als auch sämtliche Customizing-Optionen zur Verfügung. Lediglich das Verändern des Standard-Codings ist blockiert, jedoch gibt es alle Erweiterungsmöglichkeiten.
2.1 Framework-Bestandteile
SAP Activate setzt sich aus drei Teilen zusammen, die Sie nachfolgend beschrieben finden.
2.1.1 Content
Grundsätzlich liefern ERP-Systeme Standard-Content. Dazu gehören beispielsweise Muster-Organisationseinheiten, die als Vorlage dienen können, oder etwa vorgedachte Prozesse. Dies ist auch bei S/4HANA so. Folgende Punkte fasst SAP im Rahmen von SAP Activate unter dem Begriff Content zusammen:
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.2 bzw. 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 11 gesondert darauf ein.
Integration and Migration: Zur Integration und Migration liefert SAP einerseits Content, anderseits aber auch Hilfestellung in Form von Anleitungen aus.
2.1.2 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,
