28. Der rote Faden, Teil 2: Scoping & Prototyping – Zusammenfassende Empfehlung für eine sichere und effiziente Einführung von S/4HANA

Zusammenfassung; Eine sichere und effiziente Einführung von S/4HANA erfordert ein klares Scoping, das sich auf geschäftskritische Prozesse konzentriert, sowie eine iterative Prototyping-Phase, um potenzielle Probleme frühzeitig zu identifizieren und zu lösen.

 

Wie ich in der Einleitung zu BLOG-Beitrag 26 erläutert habe, bilden die „Roter Faden“ Beiträge eine Zusammenfassung der 25 vorher veröffentlichten BLOG-Beiträge nach Projektphasen:

1. Projektvorbereitung -> abgeschlossen mit dem Project-Kick-Off Meeting (s. BLOG-Beitrag 26)
2. Scoping & Prototyping -> abgeschlossen mit dem end-to-end (e2e) Prozess-Integrationstest (ohne RICEF und ohne angebundene Sub-Systeme) (aktueller Beitrag – BLOG-Beitrag 28)
3. Realisierung -> abgeschlossen mit dem end-to-end (e2e) Akzeptanztest (inkl. RICEF und angebundenen Sub-Systemen) (geplant in BLOG-Beitrag 29)
4. Implementierung -> abgeschlossen mit dem Go-Live und der vollständigen Übergabe des Systems an die Business-Owner respektive die operative Support Organisation (geplant in BLOG-Beitrag 30)

In diesem Beitrag geht es um die „Scoping & Prototyping-Phase“.

 

 

Phase 2: Scoping & Prototyping

Im Rahmen des Scoping & Prototyping werden alle Prozesse und Funktionen des künftigen S/4HANA ERP Systems bestimmt, möglichst zielgerichtet dokumentiert und als Prototyp im S/4HANA Entwicklungssystem ausgeprägt und mit realen Datenbeispielen getestet. Ferner werden die in der folgenden Phase zu realisierenden R(eports)I(nterfaces)C(onversions)E(nhancements)F(orms) identifiziert und funktional spezifiziert, wobei ich in dem Kontext auf die BLOG-Beiträge, die die I(nterfaces) und C(onversions) betreffen, verweisen möchte:

BLOG 21 – Analysieren Sie vor Projektbeginn Ihre Umsysteme und Schnittstellen

BLOG 22 – Stellen Sie von Anfang an sicher, dass Sie effektiv an der Bereinigung Ihrer Daten arbeiten und machen Sie sie Business Ready – das ist das A und O für einen Boring Go-Live

Für die sonstigen Entwicklungen beachten Sie bitte auch:
BLOG 18 – Wie kann oder sollte mit dem Begriff des „SAP Standard“ im S/4HANA umgegangen werden, und warum ist es wichtig, das festzulegen?

Wie im gesamten BLOG lege ich in den folgenden Empfehlungen die Annahme zugrunde, dass die künftigen Prozesse möglichst weitgehend an den S/4HANA Best-Practise Prozessen ausgerichtet sein bzw. auf Grundlage derer erstellt werden sollen. Ferner gehe ich davon aus, dass Sie sich eine eigene Model Company aufbauen und nicht die vorgefertigte Version der SAP benutzen -siehe dazu

BLOG 9 – Wie ist das Vorgehen auf Basis einer SAP Model-Company zu bewerten?

 

Das Vorgehen besteht im Wesentlichen aus:

Der Identifikation der im neuen System abzubildenden Prozesse und Funktionen – hierbei empfehle ich als Startpunkt zur Bestimmung der abzulösenden aktuellen Prozesse und Funktionen eine Prozessliste/Testkatalog aus einem end-to-end Test des aktuellen Systems (z.B. die vom letzten Regressionstest anlässlich eines Releasewechsels) zu verwenden – und deren Mapping zu den S/4HANA Best-Practice Prozessen der SAP. Im Sinne eines strukturierten Vorgehens sollten Sie entsprechend der folgenden BLOG-Beiträge vorgehen:

BLOG 10 – Von der Business Process Master List (BPML) über die SAP Best Practice-Prozesse und deren Abbildung in Test-Skripts bis hin zur Prozessdokumentation in einem B(usiness)P(rozess)M(anagement)-System – ein strukturierter Weg zum Aufbau der eigenen Model Company

BLOG 11 – Wie mappe ich die S/4HANA Best Practice-Prozesse in meiner Business Process Master List (BPML)?

 

 

Die kompletten Sets der in diesen BLOG-Beiträgen angesprochenen Tools, um Ihnen ein strukturiertes und effizientes Vorgehen zu erleichtern, finden Sie in unserem Digistore24:

 

>>  Business Prozess-Master-Liste (BPML) als Beispiel-Datei in MS Excel

>>  Die umfassende Liste der SAP Business Process Steps in MS Excel

Oder beides im Bundle:
>>  Bundle: Die Business Process Master Liste und die Process Steps im Paket zum Vorteilspreis

Und legen Sie in dieser Phase schon die Grundlage, die Sie in den folgenden Phasen nur noch evolutionär weiterentwickeln müssen, um zu einer aus Anwendersicht komplett getesteten und dokumentierten Lösung zu kommen. Beachten Sie also schon jetzt auch die folgenden BLOG Beiträge:
BLOG 19 – Was ist die Accelerated Testing Environment, und wie bereite ich diese vor?
Mit dem dazugehörigen Toolset:
>>  Accelerated Testing Package – alle Tools (zip) für die beschleunigte Erstellung von Testscripts Ihrer Prozesse

oder im Bundle mit der Liste der Prozess Steps:
>>  Bundle: Das Accelerated Testing Package und die Business Process Steps als Paket zum Vorteilspreis

und
BLOG 25 – Anwenderdoku? Wenn schon, dann gleich richtig: Wertsteigernde Anwenderdokumentation – ein Gesamtkonzept. Auch hierzu bieten wir Ihnen Beschleuniger zur Dokumentation der Prozesse in Ihrem BPM-System an:
>>  Die S/4HANA Best Practice-Prozessflüsse im BPMN2-Format, deutsch, HORIZONTAL

oder eben
>>  Die S/4HANA Best Practice-Prozessflüsse im BPMN2-Format, deutsch, VERTIKAL
je nachdem, welchen Standard Sie in Ihrem Hause etabliert haben.

 

Integrationstests im Integrationssystem

Der fertig ausgeprägte Prototyp sollte dann zur Abnahme im Rahmen eines ERP-end-to-end Integrationstests im Integrationssystem getestet werden – wenn Sie den Test mithilfe des Accelerated Testing Package durchführen, haben Sie einerseits eine vollständige Dokumentation der Testschritte und können zudem in den einzelnen Prozessschritten prüfen, ob Sie alle RICEF Anforderungen erfasst haben, in dem Sie Reports, Interfaces, Enhancements und Forms den jeweiligen Prozessschritten zuordnen.

Für eine Dokumentation der Prozessabläufe empfehle ich einerseits die Prozessdokumentation im BPM-System, für die Anwendungsabläufe erste Aufzeichnungen im Autorentool, um diese dann mit den späteren Anwendern zu teilen und diesen zu ermöglichen, sich interaktiv in die neuen Prozesse einzuarbeiten. Und wenn Sie Ihre Datenmigration rechtzeitig gestartet haben, sollte es vielleicht sogar schon möglich sein, diesen ersten Integrationstest teilweise auf Basis bereits migrierter Stammdaten durchzuführen – anzustreben ist dies auf jeden Fall und bei den aktuell verfügbaren Vorgehensweisen und Tools im Bereich der Datenmigration auch problemlos möglich, unter der Voraussetzung, dass Sie diesen wohl kritischsten Workstream rechtzeitig gestartet haben, siehe: BLOG 22 – Stellen Sie von Anfang an sicher, dass Sie effektiv an der Bereinigung Ihrer Daten arbeiten und machen Sie sie Business Ready – das ist das A und O für einen Boring Go-Live.

 

Weitere wichtige Kernergebnisse dieser Phase sind:

• Eine vollständige Auflistung und funktionale Spezifikation aller RICEF Objekte. Dies beinhaltet auch die Abnahme der funktionalen Specs. durch das Development Team unter Beachtung der in BLOG 18 genannten und auf Ihre Situation adaptierten Rahmenbedingungen
• Ein im Detail aktualisierter Projektauftrag (i.e. durch Erweiterung um den Business Blueprint)
• Die Training Needs Analysis 1 – Enablement Strategy (siehe dazu auch https://www.knowx.de/de/userenablement-de/) und in dem Zusammenhang auch die finale Strategie für die Anwendungsdokumentation; siehe dazu auch BLOG 25.
• Die Strategie für das Berechtigungskonzept

Wie bereits im BLOG 27 ausgeführt, ist meine Empfehlung, in dieser Projektphase in Greenfield- und Bluefield-Projekten agil zu arbeiten und am Ende das Ergebnis in einem Business Blueprint zusammenzufassen.