Martin Kipka

SAP® Activate – Agilität in SAP-Implementierungsprojekten

Martin Kipka

SAP® Activate – Agilität in SAP-Implementierungsprojekten

ISBN:978-3-96012-646-1 (E-Book)

Lektorat:Anja Achilles

Korrektorat: Team Wallmow 65

Coverdesign: Philip Esch

Coverfoto: pavel1964 | Nr. 234657662 adobe.stock.com

Satz & Layout: Johann-Christian Hanke

1. Auflage 2020

© Espresso Tutorials GmbH, Gleichen 2020

URL: www.espresso-tutorials.de

Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte sind vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.

Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch die Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.

Feedback: Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: info@espresso-tutorials.com.

Inhaltsverzeichnis

Cover

Titelseite

Impressum

Vorwort

1 Einleitung

2 Einführung in SAP Activate

2.1 Framework-Bestandteile

2.2 Die kritischen Erfolgsfaktoren in Projekten

3 Unterschiedliche Ausgangsvoraussetzungen

4 Struktur der Methode

5 Die Phasen von SAP Activate

5.1 Wasserfall oder Agil?

5.2 Iteratives Vierphasenmodell mit unterschiedlichen Roadmaps am Beispiel SAP S/4HANA

6 Prepare-Phase

7 Explore-Phase

7.1 Deliverables der Explore-Phase

7.2 Backlog

7.3 User Stories

7.4 Activate Solution und Rapid Prototyping

7.5 Fit-Gap-Workshops und Delta Design

7.6 Organisational Change Management (OCM)

7.7 Legacy Data Migration

7.8 Realize and Sprint Planning

8 Exkurse

8.1 Mit oder ohne SAP Solution Manager

8.2 Best Practice Content

8.3 Alternative Tools

9 Realize-Phase

9.1 Deliverables der Realize-Phase

9.2 Sprint Planning

9.3 Sprint Execution (Configuration)

9.4 Daily Team Meeting

9.5 Scrum of Scrums

9.6 Walkthrough/Review

9.7 Data Migration

9.8 End-to-End-Tests

9.9 Operations Setup

9.10 Retrospective

10 Deploy Phase

10.1 Deliverables der Deploy-Phase

11 Beschleuniger/Accelerator

11.1 SAP Best Practices

11.2 Best Practice Explorer

11.3 Roadmap Viewer

11.4 SAP Jam

12 Rollen und Verantwortlichkeiten

12.1 Rollen im SAP-Activate-Projekt

12.2 Ein neues Mindset

12.3 Chicken and Pigs

12.4 Stakeholder Management

12.5 »Aber unsere Mitarbeiter benötigen Führung«

13 Aber ein Wasserfall ist auch toll (kritische Würdigung)

13.1 ASAP und andere Wasserfall-Modelle im Vergleich zu SAP Activate

13.2 SAP Activate im Vergleich zu einem reinen Scrum-Projekt

13.3 Agile Mythen

13.4 Projektmythen

14 Risikomanagement

15 Ihr Weg in ein S/4HANA-Projekt mit SAP Activate

15.1 Fragen zur Planung

15.2 Fragen zur Organisation

15.3 Tracking und Monitoring

15.4 Reviewing

15.5 Issue Management

15.6 Konfigurations- und Transportmanagement (Change Control)

15.7 Risikomanagement

15.8 Qualitätssicherung (QS)

16 Zusammenfassung

A Anhang mit Checklisten

Definition of Ready

Definition of Done

Definition of Shipable

Agile-Fitness-Check

B Der Autor

C Disclaimer

Willkommen bei Espresso Tutorials!

Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.

Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: http://www.fico-forum.de.

Eine Auswahl weiterer Bücher von Espresso Tutorials:

 Jörg Marenk:IT-Projektmanagement im SAP® Solution Manager

 Stefan Körner & Christina Dietrich:Testautomatisierung mit dem SAP® Solution Manager

 Andreas Schuster:Praxishandbuch SAP® HANA – Administration

 Andreas Unkelbach:SAP® S/4HANA Migration Cockpit – Datenmigration mit LTMC und LTMOM

 Manfred Sprenger:Praxishandbuch SAP®-Basis – Troubleshooting in der Systemadministration

Vorwort

Die SAP hat alle ihre Kunden informiert, dass bis Ende 2027 das Upgrade auf S/4HANA abgeschlossen sein sollte, da zu diesem Zeitpunkt die normale Wartung für die SAP Business Suite 7 eingestellt wird. Von da an wird es noch bis Ende 2030 eine optionale Extended-Wartung geben. Dies fordert nun von allen Unternehmen, die ein SAP ERP in ihrer Systemlandschaft betreiben, über den Upgrade-Prozess nachzudenken. Während erste Unternehmen diesen bereits abgeschlossen haben und weitere sich zurzeit mitten im Prozess befinden, zögern andere noch, beispielsweise weil man sich damit schwertut, die in der Vergangenheit getätigten Investitionen in Eigenentwicklungen, User-Exits, Schnittstellen und Stammdatenerweiterungen zu verwerfen, um auf die neue Technologie der SAP umzusteigen. Vor dem Hintergrund, dass SAP-Implementierungsprojekte nicht gerade im Ruf stehen, besonders rasch und lautlos über die Bühne zu gehen, gewinnen Fragestellungen nach dem richtigen Projektvorgehen eine elementare Bedeutung.

In der IT-Welt wird alle paar Jahre »eine neue Sau durch das Dorf getrieben«, die unsere schöne, bunte Welt noch einfacher und besser machen soll – und das gilt eben auch für Vorgehensmodelle in Projekten. Zurzeit heißt diese Sau »Agile«.

Auch in Walldorf kann und will man sich dem Buzzword »Agile« nicht verschließen, und so wurde mit SAP Activate ein neues Implementierungs-Framework vorgestellt. Unter Einbeziehung agiler Techniken verspricht es ein Vorgehensmodell, das die Einführung oder den Umstieg auf SAP S/4HANA einfacher, schneller und günstiger machen soll. SAP sieht diese Implementierungsmethode nun auch für andere Produkte vor. Mithilfe von SAP Activate sollen zukünftig alle Implementierungen durchgeführt werden, die bisherigen Vorgehensweisen ASAP und SAP Launch werden nicht mehr weiterentwickelt.

Im vorliegenden Werk möchte ich das theoretische Hintergrundwissen zur Projektmethodik von SAP Activate vermitteln, aber auch die Grenzen aufzeigen, welche mir in der Praxis begegnet sind oder berichtet wurden, denn ein Fokussieren ausschließlich auf Agilität ist noch kein Garant für den Implementierungserfolg.

Insofern richtet sich dieses Buch an jene Leser, die bisher noch keine Erfahrungen in SAP-Activate-Projekten sammeln konnten. Sicherlich wird es das Lesen erleichtern, wenn Sie bereits grundlegendes Verständnis für Projektvorgehensmodelle haben, aber es ist keine Voraussetzung. Zielgruppe dieses Leitfadens können sowohl Mitglieder aller Ebenen eines bereits initiierten bzw. laufenden Implementierungsprojekts sein als auch Mitarbeiter eines Unternehmens, in denen ein solches Projekt ansteht, die nur mittelbar – vielleicht in der Rolle eines Stakeholders – mit dem Projekt zu tun haben, und die nun die neuen Fachbegriffe des Projektteams verstehen wollen.

Neben den theoretischen Grundlagen des Modells finden Sie immer wieder Tipps aus der Praxis und einige Links, hinter denen Sie weiterführende Informationen oder projektunterstützende Vorlagen finden.

Die Veröffentlichung dieses Buches fällt in die Zeit, in der die Gesellschaft in Europa sich intensiv mit dem Virus Covid-19 befassen muss. Gerade erst beschäftigte man sich mit einer Rückkehr in eine Art »Normalität«, schon müssen die meisten Staaten in den nächsten Lockdown gehen. Das Management auf allen Unternehmensebenen hat in den vergangenen Monaten intensiv dazugelernt: Statt langfristiger Budgetplanung hat kurzfristiges Agieren in kleinen Teams das unternehmerische Handeln bestimmt. Agilitätskonzepte, die ggf. schon vor Corona erörtert wurden, sind nun erheblich stärker in den Fokus gerückt und werden nachhaltiger verfolgt. Insgesamt wird die Arbeitswelt flexibler. Von der Politik, die im Krisenmodus das Land von Tag zu Tag und Woche zu Woche geführt hat, konnte man durchaus lernen. Gleiches gilt für die Digitalisierung: Hat in der Vergangenheit bereits allein die Entscheidungsfindung Monate, manchmal gar Jahre in Anspruch genommen, wurde jetzt regelmäßig die direkte Umsetzung erzwungen – und das in einem Bruchteil der Zeit.

Weltweit haben Menschen sehr viel häufiger digital kommuniziert und digitale Dienstleistungen in Anspruch genommen. Vieles davon wird bleiben und den Unternehmen neue Chancen eröffnen. Allerdings wird es auch zu einer Marktbereinigung kommen. Die meisten Verweigerer der Digitalisierung dürften zu den Verlierern dieser Veränderungsprozesse gehören. Arbeiten von Zuhause aus wird ermöglicht und erleichtert die Entscheidung, im Grünen zu wohnen, weil die zeitlichen und finanziellen Aufwendungen für die Fahrt zum Arbeitsplatz abnehmen. Regionen, die eine entsprechende digitale Infrastruktur bereithalten, sowie jene Unternehmen, die ihre Produkte aus der Cloud bereitstellen, werden wohl davon profitieren. Seit Jahren verfolgt die SAP diesen Weg, und nun bekommt er einen unerwarteten Beschleuniger.

Warum so viel (D)Englisch?

Ich möchte mich grundsätzlich vorab für das »Denglisch« in diesem Buch entschuldigen. Die IT wird zunehmend anglifiziert, und ich selbst empfinde es inzwischen als holpriger, wenn ich mich etwas verkrampft darum bemühe, jeden in der Praxis inzwischen eher gängigen englischen Begriff ins Deutsche zu übersetzen. Das mag aber der eine oder andere Leser anders bewerten. Ich hoffe, dass Sie trotzdem Gefallen an den Inhalten finden und mir folgen können. Apropos: Aus genau diesem Grund sind auch die meisten Abbildungen von SAP Activate in Englisch.

Danksagung

Nachdem ich im vergangenen Jahr nahezu durchgängig in agilen Projekten unterwegs war und mehrere SAP-Activate-Schulungen für das große Walldorfer Softwareunternehmen gegeben habe, ergab sich nun endlich ein Zeitfenster, in dem ich dieses kleine Werk vollenden durfte. Dazu trägt mein langjähriger Geschäftspartner Tony Dittmann bei, ohne den dieser Freiraum ganz sicher nicht entstanden wäre. Deshalb gebührt ihm auch mein ganz besonderer Dank.

Bevor ich Sie nun in das Vorgehensmodell »entführe«, möchte ich es außerdem nicht versäumen, Anja Achilles vom Verlag Espresso Tutorials für ihr Lektorat zu danken. Sie hat mir viele wertvolle Tipps gegeben, die allen Lesern dieses Büchleins zugutekommen. Auch ihre Geduld mit mir möchte ich hervorheben.

November 2020, Martin Kipka

Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:

Hinweis

Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.

Beispiel

Beispiele dienen dazu, ein Thema besser zu illustrieren.

Achtung

Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.

Die Form der Anrede

Um den Lesefluss nicht zu beeinträchtigen, wird im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform verwendet, stets aber die weibliche Form gleichermaßen mitgemeint.

Hinweis zum Urheberrecht

Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.

1 Einleitung

SAP Activate ist ein Framework zur Einführung von SAP S/4HANA und weiteren SAP-Produkten. Es wird seitens der SAP für Kunden kostenfrei zur Verfügung gestellt und löst die bisherigen Vorgehensmodelle ASAP und SAP Launch ab.

Auch wenn SAP Activate nicht ausschließlich zur Implementierung von S/4HANA vorgesehen ist, werde ich mich im vorliegenden Büchlein auf diese Funktion fokussieren. Dafür gibt es drei Gründe: Zum einen ist keine andere Software der SAP in der Implementierung derart komplex und herausfordernd wie das ERP-System S/4HANA und somit ist der Mehrwert für die meisten Leser bei diesem Beispiel wohl am größten. Zum anderen ist keine andere Software der SAP ähnlich verbreitet wie das ERP-System, sodass die Zielgruppe damit wohl ebenfalls am größten sein dürfte. Schließlich ist mein eigener Erfahrungshorizont in dieser Hinsicht schlicht und ergreifend am besten ausgeprägt. So kann meine Praxiserfahrung dem Inhalt und der Lesbarkeit in Form von Beispielen zugutekommen.

SAP-Projekte haben eine nicht zu unterschätzende Komplexität. Dies lässt sich schon am Produkt »ERP-Software« erkennen, welches dafür ausgelegt ist, sämtliche betriebswirtschaftlich relevanten Vorgänge eines Unternehmens abzubilden – also alle geplanten und tatsächlichen Ströme von Gütern und Dienstleistungen sowie die dazugehörigen Werteflüsse. Somit liegt einem SAP-Projekt stets das komplette Input-/Output-Modell (siehe Abbildung 1.1) des Unternehmens inklusive der damit verbundenen Geschäftsprozesse zugrunde. Dies unterscheidet ERP-Software von Branchenlösungen oder Insellösungen, die stets nur Teile der Unternehmensprozesse verarbeiten.

Abbildung 1.1: Einfaches Input-/Output-Modell

Die gesamten Prozesse sollen in einem einzigen SAP-System abgebildet werden. Derartig umfassende Projekte können nicht ohne Herausforderungen bleiben. Dabei kommen zu den Mengen- und Werteflüssen auch noch Daten hinzu, die im Rahmen der Planung entstehen. Zudem sind die Anforderungen an ein modernes Berichtswesen in den letzten Jahren gestiegen. Schließlich erwarten moderne Unternehmen eine selbstlernende Software, um sehr schnell auf den Markt oder die Kunden reagieren zu können. Entsprechende Stichworte sind beispielsweise »Cross Selling« und »Upselling«, wo die Software das Kaufverhalten mehrerer Kunden eigenständig analysieren soll, um anderen Kunden entsprechende Vorschläge zu unterbreiten. Oder »Predictive Maintenance«, also das Auswerten von Maschinendaten, um Stillstand zu vermeiden, indem die Wartung durchgeführt wird, bevor es zum Ausfall kommt. Ein weiteres Stichwort wäre die Zusammenarbeit mit anderen Systemen, z.B. für die Blockchain-Technologie.

Somit kommt es im Rahmen eines solchen Software-Implementierungsprojekts unweigerlich zu der Frage, ob das System an die Prozesse des Unternehmens angepasst werden soll oder ob das Unternehmen die Standardsoftware, so wie vom Hersteller angeboten, unverändert verwenden kann und will – was in der Regel auf eine Anpassung von Prozessen hinausläuft (siehe Abbildung 1.2).

Abbildung 1.2: Unternehmens- versus Softwareanpassung

Diese Fragestellungen sind die grundlegenden Herausforderungen im Rahmen von Implementierungsprojekten. In den meisten Projekten ist es natürlich kein Entweder-oder, sondern ein Sowohl-als-auch. Dies bedeutet, dass sich das Unternehmen einerseits für alles, was möglichst nah am Standard der Software bleiben soll, mit dem Organisational Change Management (OCM) auseinandersetzen muss. Andererseits muss es für diejenigen Prozesse, welche die Stärke des Unternehmens ausmachen oder sogar zu den »Unique Selling Propositions« gehören, die Anpassung der Software in Betracht ziehen. Im Rahmen einer S/4HANA-Implementierung geschehen diese Anpassungen innerhalb des Projekts durch Customizing, das Entwickeln von User Exits (Kundenerweiterungen unter Verwendung einer bestimmten Technologie), ABAP (Kundenerweiterungen unter Verwendung der SAP-eigenen Programmiersprache), Schnittstellen und den Einsatz von Fremd- und/oder Partnerlösungen.

Auch SAP-Projekte können sich nicht den üblichen Zielkonflikten von Zeit, Geld und Qualität entziehen. Versucht man, im Rahmen der Projektarbeit nur einen dieser drei Punkte »anzufassen«, so wirkt sich dies fast immer auf beide, mindestens aber auf einen der anderen Punkte aus.

Schließlich stellt das Management des Unternehmens noch ganz eigene Ansprüche an derartige Projekte, was ich in einigen stereotypen Anforderungen formulieren möchte:

Typische Projektanforderungen seitens des Managements

 Unser System ist im Laufe der Jahre immer mehr »verbogen« worden, jeder neue Patch wird inzwischen zur Herausforderung. Wir möchten zurück zum Standard.

 Wir wollen das Projekt auch dazu nutzen, unsere Prozesse (weltweit) zu harmonisieren.

 Leider wussten wir zu Projektbeginn noch nicht, dass wir dieses Unternehmen/diesen Unternehmensteil (ver-)kaufen werden. Es muss noch »irgendwie« mit im Projekt berücksichtigt werden.

Und nun kommt die SAP mit einem neuen Framework zum Implementierungsvorgehen, das Lösungen für all diese Herausforderungen bieten soll: SAP Activate! Entdecken Sie auf den kommenden Seiten die Chancen und die Besonderheiten, aber auch die Grenzen dieses Tools. Viel Spaß beim Lesen!

2 Einführung in SAP Activate

SAP Activate bietet ein einheitliches Framework zur Implementierung von SAP-Software für die unterschiedlichen Kundenausgangslagen, wie etwa eine Neueinführung, das Upgrade einer bestehenden SAP-Landschaft oder eine Transformation aus anderen Non-SAP-Systemen.

Die Grundpfeiler von SAP Activate sind der Content, die neue Methodologie mit agilen Ansätzen in Kernphasen des Projekts sowie Tools z.B. zur geführten Konfiguration eines SAP-Cloud-Systems, auch Guided Configuration genannt (siehe Abbildung 2.1).

Abbildung 2.1: Überblick zu SAP Activate

Wenn Kunden heute über die Implementierung von SAP S/4HANA nachdenken, dann liegen unterschiedliche Ausgangsszenarien zugrunde:

 Der Kunde hat noch kein ERP-System und möchte eine Neueinführung vornehmen.

 Der Kunde hat bereits ein SAP ERP im Einsatz und möchte jetzt zu S/4HANA wechseln.

 Der Kunde verfügt bereits über ein ERP-System, dieses ist jedoch von einem anderen Hersteller.

 Die Ausgangslage ist eine Mischung aus den vorgenannten Punkten, je nach Unternehmensteil.

Vom SAP-Activate-Framework werden diese unterschiedlichen Ausgangssituationen beim Kunden ebenso unterstützt wie die diversen, heute üblichen Bereitstellungsszenarien:

 On-Premise,

 Cloud,

 Hybrid, also eine Mischung aus On-Premise und Cloud.

Hinsichtlich der Cloud bietet die SAP ihren Kunden zwei unterschiedliche Optionen an:

S/4HANA Cloud Multi Tenant Edition (S/4HANA MTE): Diese Form der Bereitstellung ist für Kunden geeignet, die weitgehend dazu bereit sind, die SAP-Standardprozesse zu nutzen. Mehrere Unternehmen werden auf einer Serverlandschaft gemeinsam abgebildet (datentechnisch sind sie selbstverständlich strikt voneinander getrennt!). Diese Option bringt einige Einschränkungen hinsichtlich der Anpassbarkeit des SAP-Systems mit sich, dafür sind die Projektlaufzeiten in der Regel sehr kurz, und das System wird seitens der SAP immer auf dem aktuellen Stand gehalten. Vierteljährlich 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, 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 neuen Prozessen vertraut gemacht und blockiert kurz vor dem geplanten Produktivsetzungstermin – mal begründet und manchmal einfach nur aus Unmut über die mangelnde (rechtzeitige) Einbindung.

 Das Projekt ist auf Kundenseite suboptimal besetzt. Nicht die Mitarbeiter mit den besten Prozesskenntnissen stehen dem Projekt zur Verfügung, sondern jene, die gerade Zeit hatten.

 Das Projekt ist seitens des Implementierungspartners suboptimal besetzt. Nicht die Mitarbeiter mit den passenden Skills, sondern die Mitarbeiter, die gerade kein anderes Projekt haben, werden entsendet.

 Der Lenkungsausschuss entscheidet träge oder verschiebt seine Zusammenkünfte immer wieder.

 Innovationen führen zu einer Veränderung des Projektinhalts und damit zu Veränderungen mit Blick auf die zu liefernde Qualität.

 Durch Weiterentwicklung des Geschäftsmodells gibt es kundenseitig neue Anforderungen.

 Zu Beginn des Projekts lässt man gewisse Unschärfen im Zeitmanagement durchgehen, weil sich die Gesamtdauer ja noch gut »anfühlt«.

Häufig führen Change Requests auch zu einer Abkühlung des Vertrauensverhältnisses zwischen den Partnern. Am Ende geht es schließlich regelmäßig darum, wer für den veränderten Aufwand geradesteht.

Dieser in vielen Projekten immer wieder aufkeimende Konflikt von Change Requests wird nach der SAP-Activate-Methode idealerweise so gelöst, wie es in agilen Projektvorgehensmodellen üblich ist: Man verzichtet auf das aufwendige Abfassen von Sollkonzepten. In agilen Projekten geht man grundsätzlich davon aus, dass es im Projektverlauf neue Anforderungen geben wird. Technischer Fortschritt, die Weiterentwicklung des Unternehmens oder einfach nur späte Erkenntnisse sind die Ursachen für solche unvorhergesehenen Projektanforderungen. Statt nun jedes Mal darüber nachzudenken, den Projektumfang auszuweiten, wird überlegt, welche Funktionalitäten der neuen Anforderung weichen müssen. Es wird also neu priorisiert. Diese Aufgabe kommt zwingend einem Mitarbeiter des Kunden im Projekt zu. Man nennt diese Rolle »Product Owner«.

Abbildung 2.5 stellt die Herangehensweise dar. Aufgrund dieses Ansatzes bleibt die Grundfläche des Dreiecks unverändert. Ihr Inhalt hingegen, also die Teilleistungen, werden im Projektverlauf regelmäßig hinterfragt und ggf. mit anderen Prioritäten versehen. Neue wichtige Anforderungen auf der einen Seite können also weniger wichtige Anforderungen auf der anderen Seite aus dem Projektumfang verdrängen.

Abbildung 2.5: Change in SAP Activate

Diese Verfahrensweise erspart manche leidige Diskussion zwischen dem Implementierungspartner und dem Kunden hinsichtlich Klarheit, Vollständigkeit und Richtigkeit des Sollkonzepts als Maß für den Projekterfolg. Allerdings kann dieses Vorgehen interne Konflikte bei den Kunden verursachen. Da in der Praxis hinter einer verdrängten Funktionalität häufig ein anderer Verantwortlicher steht als hinter der neuen, die es nun in den Scope des Projekts geschafft hat, werden die unterschiedlichen Stakeholder jeweils um den Erhalt ihrer Funktionalitäten ringen. Deshalb ist ein starker Product Owner ein kritischer Erfolgsfaktor für dieses Vorgehen. Er sollte über einen profunden Rückhalt im Lenkungsausschuss und in der gesamten Organisation verfügen.

Neben dem ständigen Ringen um die Prioritäten führt das agile Modell noch zu weiteren Herausforderungen im Projekt. Nehmen wir einmal an, dass eine Funktion der Finanzbuchhaltung eine Funktion des Vertriebs aus dem Release verdrängt, so stellt sich unmittelbar die Frage, ob dafür überhaupt die geeigneten Ressourcen für das Projekt eingeplant sind, oder ob durch die neue Priorität Engpässe bei bestimmten Projektmitarbeitern entstehen.

Sie sehen, dass es hinsichtlich des Projektvorgehens manches zu beachten gibt. Somit ist es für Projekte, die mit SAP Activate umgesetzt werden, wichtig, die üblichen Erfolgsfaktoren Zeit, Geld und Qualität unter geänderten Vorzeichen zu betrachten.

Bevor wir dies in Kapitel 5 beginnen, möchte ich ein paar Begriffe einführen, die dem Verständnis des Modells dienen, da sie die Methode gliedern, ihr also eine überschaubare Struktur geben.

3 Unterschiedliche Ausgangsvoraussetzungen

Jeder Kunde, der SAP Activate im Rahmen einer S/4HANA-Implementierung einsetzen möchte, kommt aus einer ganz eigenen Historie. Dennoch lassen sich diese unterschiedlichen Ausgangslagen gruppieren. Die SAP spricht hier von unterschiedlichen Transitionspfaden (Transition Paths).

Ganz grob lassen sich zunächst einmal drei Transitionspfade unterscheiden:

 System Conversion: Hierbei handelt es sich um eine mehr oder minder technische Überführung eines vorhandenen SAP-ERP-Systems in ein S/4HANA-System. Technische Neuerungen werden dabei ggf. eine Zeit lang ausgeblendet, bzw. nur in zwingend erforderlichem Umfang berücksichtigt. Der Kunde möchte im Grunde sein bisheriges System weiterbetreiben und zieht auf S/4HANA um, damit er nicht aus der Wartung läuft und seine bisher in das System gesteckten Investitionen erhalten bleiben. Dieser Umzug wird häufig als Brownfield Approach bezeichnet. Für die System Conversion stellt die SAP den Software Update Manager bereit. Dieser Transitionspfad führt regelmäßig zu einer S/4HANA-Installation auf kundeneigenen Systemen (On-Premise).

 New Implementation: Die Ausgangsbasis kann zum Projektbeginn ein SAP- oder ein Non-SAP-System sein. Der Kunde entscheidet sich ungeachtet des vorhandenen Systems dazu, auf der grünen Wiese zu beginnen. Bei der Übernahme der Daten aus dem Altsystem unterstützt das S/4HANA Migration Cockpit. Mitunter wird dieser Ansatz Greenfield Approach genannt. Dieser Transitionspfad ist auch für Unternehmen geeignet, die bisher noch kein ERP-System einsetzen. Dabei kann das angestrebte S/4HANA-System sowohl in der Cloud als auch On-Premise liegen.

 Selective Data Transition: Bei diesem Transitionspfad geht es um den Investitionsschutz des bisherigen Bestands. In bestimmten Unternehmensbereichen oder Prozessen soll ein Prozess-Redesign vermieden werden, wohingegen andere Prozesse oder Unternehmensbereiche aktiv neu zu gestalten sind. Die SAP stellt hierfür das Tool Landscape Transformation bereit. Das Zielsystem ist entweder ein On-Premise-System oder die S/4HANA Cloud Single Tenant Edition (Kunde hat ein eigenes, physikalisch von anderen Kundensystemen getrenntes SAP-System). Dieses Vorgehen wird mitunter als Bluefield Approach bezeichnet.

In Abhängigkeit vom gewählten Transitionspfad und dem Zielsystem (Cloud oder On-Premise) ändern sich die Aufgaben in den unterschiedlichen Phasen des Projekts leicht. Daher ist es wichtig, dass diesbezüglich schnell Einigkeit und Klarheit hergestellt wird. Beachten Sie bitte, dass im Roadmap Viewer jeweils angepasste Versionen der Unterstützung existieren. Ebenso sind für den einen oder den anderen Transitionspfad spezifische Beschleuniger vorhanden.

4 Struktur der Methode

Im ausklingenden letzten Jahrtausend bin ich noch in nahezu jedem SAP-Projekt auf ein anderes Vorgehensmodell gestoßen. Im Grunde folgte jedes Beratungsunternehmen seiner eigenen Methodik. Zwar ähnelten sich alle Projekte dahingehend, dass sie wasserfallbasiert und in Phasen gegliedert waren, aber sowohl die Anzahl der Phasen als auch die Begrifflichkeiten waren stets ein wenig anders. Heute stellt die SAP all ihren Kunden und Partnern die Activate-Methode inkl. Beschleuniger und jeder Menge Informationsmaterial zur freien Verfügung. Daher lohnt es sich, einen genaueren Blick auf die Struktur der Methode und ihre Begrifflichkeiten zu werfen. Anders als bei ASAP scheint sich dieses Vorgehensmodell am Markt zunehmend durchzusetzen.

Die strukturierenden Elemente der Methode werden wie folgt bezeichnet:

 Phase – Eine Phase beschreibt einen bestimmten Fortschritt im Projekt. Jede Phase endet mit einem sogenannten Quality Gate, also mit einer Prüfung, ob die für die Phase geplanten Aktivitäten erfolgreich abgeschlossen wurden. Abbildung 4.1 zeigt z.B. die Deploy-Phase.

 Workstream – Workstreams (linke Spalte in Abbildung 4.1) beschreiben Bündel zusammenhängender Aufgaben. Ein Workstream, z.B. das Projektmanagement in der Abbildung, kann mehrere Phasen überspannen. Häufig wird ein Workstream von einem festen Team von Mitarbeitern bearbeitet.

 Deliverable – Dies ist ein erwartetes Projektergebnis. Mehrere Deliverables werden einem Workstream zugeordnet. Der »Production Cutover« ist beispielsweise ein Deliverable für den Workstream »System and Data Migration«.

 Task – Ein Task ist eine zu erledigende Aufgabe. Ein oder mehrere Tasks beschreiben ein Deliverable. Die Tasks sind in der Grafik nicht mehr abgebildet. Zum Deliverable »Production Cutover« gehört beispielsweise eine ganze Reihe von Tasks, die Sie in Abschnitt 10.1.2 nachlesen können.

Abbildung 4.1 veranschaulicht die verschiedenen Begriffe noch einmal.

Abbildung 4.1: Struktur der Methode am Beispiel der Deploy-Phase

Häufig taucht die Frage auf, welche Workstreams ein Projekt benötigt. Nachstehende Auflistung zeigt eine entsprechende Empfehlung der SAP:

 Projektmanagement – Das Projektmanagement beinhaltet Planung, Terminplanung, Governance, Kontrolle und Überwachung der Projektdurchführung.

 Application: Design & Configuration – Dieser Workstream umfasst die Validierung des Scopes, die Identifizierung von Anforderungen an detaillierte Geschäftsprozesse, die Fit-Gap-Analyse sowie das funktionale Design der Lösung; außerdem: Konfiguration, Einrichtung und Komponententest des Systems (ohne kundenspezifische Entwicklung) zur Erfüllung der Kundenanforderungen pro Lösungsansatz.Zu den Elementen, die konfiguriert werden können, gehören: Formulare, Workflows, Benutzerberechtigungen und -Sicherheit, Screenlayouts, Berichte, Stammdaten-Set-up, Benachrichtigungen etc. Zur Erlangung der Kundenakzeptanz und zur Identifizierung der für die nächste Iteration erforderlichen Anpassungen beinhaltet dieser Workstream schließlich nach jedem Iterationszyklus die Demonstration der konfigurierten/entwickelten Lösung für das Kundenprojektteam. Schließlich sind RICEFW-Leistungen und Data-Volume-Management-Inhalte weitere Bestandteile.

Was bedeutet RICEFW?

 R = Reports: Berichte und Auswertungen aus dem System

 I = Interfaces: Schnittstellen zu externen Systemen

 C = Conversions: Konvertierungen zwischen unterschiedlichen Dateiformaten, z.B. für die Migration oder auch im Rahmen der Schnittstellen

 E = Enhancements: Erweiterungen, die über das Customizing hinausgehen, also Programmierung erfordern

 F = Forms: Formulare, in denen das Layout bestimmter Belege, z.B. von Bestellungen oder Rechnungen, definiert wird.

 W = Workflow: Hierbei geht es darum, bestimmte Abläufe im Unternehmen softwaregesteuert zu automatisieren und einen regelkonformen Ablauf sicherzustellen.

 Application: Testing – umfasst Teststrategie, Planung und Testfallentwicklung sowie die Durchführung von Integrations-, Performance-, System-, Regressions- und User-Acceptance-Tests.

 Application: Solution Adoption – umfasst die Nutzenanalyse, das Organisational Change Management (OCM) und das Endbenutzertraining.

 Analytics – Dieser Workstream deckt die analytischen Aspekte eines SAP-S/4HANA-Implementierungsprojekts ab.

 Application: Customer Team Enablement – umfasst die Befähigung des Kundenteams, effektiv an dem Projekt zu arbeiten. Dazu gehören die Erläuterung der Standard-Produktausrichtung, um den Kunden auf die Diskussionen zu den Systemanforderungen und das Systemdesign vorzubereiten, sowie Key-User- und Admin-Trainings zur Vorbereitung des Kunden auf die Testfallentwicklung und Testdurchführung. Die Aufgaben führen zu einem vollständigen Enablement des Projektteams.

 Custom Code Extensions – umfasst das Design und die Entwicklung von Systemfunktionen, die nicht durch das Standardprodukt bereitgestellt werden können und deshalb individuell entwickelt werden müssen. Anmerkung: Der Schwerpunkt liegt auf der Erweiterbarkeit der Lösung über RICEFW hinaus, welche ja bereits im Workstream »Design Configuration & Integration« behandelt werden.

 System & Data Migration – umfasst die Erkennung, Planung und Ausführung der Übertragung von Altdaten auf das neue System sowie deren Archivierung. Dieser Arbeitsablauf beinhaltet außerdem Umstellungsplanung, -vorbereitung, -management und -durchführung von allen Aufgaben zur Überführung des Systems in die neue Produktivumgebung. Dazu gehört auch der Zeitraum der Hyper-Care-Unterstützung kurz nach der Umstellung.

 Technical Architecture & Infrastructure – umfasst die Lösungslandschaft, das Bereitstellungskonzept, die Systemarchitektur, das technische Systemdesign, die Umgebung (Entwicklung, Test, Produktion, Failover), das Set-up, die Standards und den Prozess des Technologiebetriebs.

 Transition to Operations – umfasst das Aufsetzen und die Einrichtung der Prozesse Helpdesk, Incident Management, Post-go-live Change Management sowie die benutzerbezogenen Betriebsstandards und Prozesse.

Natürlich können Sie Ihr Projekt auch anders zuschneiden. Insgesamt liegt der Schwerpunkt vieler Projekte sicherlich im zweiten Workstream »Application: Design & Configuration«. Meistens werden hier die SAP-Module wie Finanzwesen & Controlling (FI/CO), Fertigung (PP), Beschaffung (MM) oder Vertrieb (SD) dazu verwendet, mehrere Teams parallel arbeiten zu lassen. Dieser Zuschnitt orientiert sich nach wie vor an der Ausbildung der Berater. Denkbar und langfristig erfolgversprechender wäre aus meiner Sicht eine Aufteilung in End-2-End-Prozesse. Dies setzt einerseits voraus, dass die Berater in der Lage sind, den gesamten Prozess im Customizing modulübergreifend einzustellen, erwartet andererseits aber auch auf der Kundenseite eine Organisation, die in der Lage ist, Entscheidungen entlang des Prozesses zu treffen. Häufig ist die Unternehmensaufbauorganisation ebenfalls noch an Abteilungen und nicht am Prozess ausgerichtet.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.