29. Der rote Faden, Teil 3: Realisierung – zusammenfassende Empfehlung für eine sichere und effiziente Einführung von S/4HANA

Zusammenfassung: Die Einführung von S/4HANA erfordert eine gründliche Planung, klare Ziele und eine sorgfältige Umsetzung, um Sicherheit und Effizienz zu gewährleisten. Es wird empfohlen, für die Realisierung einen erfahrenen Partner hinzuzuziehen und den Fokus auf Schulungen, Tests und Datenmigration zu legen.

 

Wie ich in der Einleitung zu BLOG 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 26)
2. Scoping & Prototyping -> abgeschlossen mit dem end-to-end (e2e) Prozess-Integrationstest (ohne RICEF und ohne angebundene Sub-Systeme) (s. BLOG 28)
3. Realisierung -> abgeschlossen mit dem end-to-end (e2e) Akzeptanztest (inkl. RICEF und angebundenen Sub-Systemen) (aktueller Beitrag: BLOG 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 30)

In diesem Beitrag geht es um die Realisierung.

Phase 3: Realisierung

Im Rahmen der Realisierung werden die in der vorherigen Phase identifizierten R(eports)I(nterfaces)C(onversions)E(nhancements)F(orms)W(orkflows) technisch spezifiziert und realisiert.

Rückblickend ist es aus meiner Erfahrung nach wie vor am wichtigsten, im Rahmen der Zusatzentwicklungen den Scope vollständig und eindeutig zu definieren und dann auch entsprechend zu managen. Hierbei geht es zum einen darum, festzulegen, welche RICEF Objekte überhaupt zu entwickeln sind und zum anderen, was diese dann schlussendlich beinhalten bzw. leisten sollen.

 

Nachstehend finden Sie die aus meiner heutigen rückblickenden Sicht wesentlichen Best Practice-Prinzipien für die einzelnen Entwicklungs-Objektarten. Dem liegen generell folgende Gedanken zugrunde:

• Mit jeder zusätzlichen Entwicklung erstelle ich etwas, was später nicht vom SAP support unterstützt wird; ich limitiere also meinen Nutzen aus dem SAP Standard Support. Zudem verursachen viele vordergründig vermeintlich „kleine“ Entwicklungen, wie die Erweiterung der Stammdatenfelder häufig eine Reihe von Folgeentwicklungen, die häufig nicht in die initiale Bewertung eingeflossen sind – dieses Problem hat sich meiner Wahrnehmung nach durch die allenfalls notwendigen Anpassungen von analytischen FIORI Apps im S/4HANA noch verschärft
• Mit jeder zusätzlichen Entwicklung begebe ich mich ein Stück weit in die individuelle personelle Abhängigkeit von dem jeweiligen Entwickler; auch wenn die Mär existiert, dass man dies durch entsprechend strukturierte Programmierung und gute vollständige Dokumentation vermeiden kann, findet dies in 90% der Projekte nicht statt, weil schlussendlich der zeitliche Druck zu groß wird … und nachgearbeitet wird das in den meisten Fällen dann auch nicht mehr. Ich zumindest habe diverse Situationen erlebt, in denen Eigenentwicklungen im SAP nicht mehr weiter betrieben werden konnten, weil der letzte Entwickler, der daran noch mitgearbeitet hat und die Entwicklung warten konnte nicht mehr zugreifbar war. An sich ein Risiko, was man durch den Einsatz einer Standard-Software ausschließen wollte.
• Es werden in den meisten SAP-Projekten sehr große Beträge für Entwicklungen aufgewendet, die sich nach einer kurzen Zeit als obsolet erweisen und nicht mehr genutzt werden; hierbei handelt es sich insbesondere um Reports, Formulare und die Migration historischer Datenbestände.

Aus dem Grunde würde ich bereits dem Scoping der Entwicklungsobjekte (vor der Realisierung) folgende Prinzipien zugrunde legen:

R(eports): Es werden grundsätzlich während des Einführungsprojektes keine Reports entwickelt. Ausnahmen können sein (diese sollten immer nachgewiesen werden müssen):
1. Gesetzlich in einem bestimmten Format vorgeschriebene Reports (wobei diese im SAP Standard enthalten sein müssten)
2. Direkt vom Eigentümer oder wichtigen Geschäftspartnern in einem definierten Format verlangte Reports

Es sollten ansonsten davon ausgegangen werden, dass die Informationsbedarfe der Fachabteilungen mit den im SAP-Standard zur Verfügung stehenden Möglichkeiten befriedigt werden können und stellt sich nach dem Produktivstart heraus, dass dies punktuell nicht der Fall ist, lässt sich mit den umfassenden Möglichkeiten des embedded BI im S/4HANA sicherlich zeitnah Abhilfe schaffen.

I(nterfaces): Siehe BLOG 21 – Analysieren Sie vor Projektbeginn Ihre Umsysteme und Schnittstellen – Vorschlag für einen strukturierten Ansatz bei der Umstellung auf S/4HANA: „Integration Solution Advisory Methodology (ISA-M)”

C(onversions): 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.
Definieren Sie in dem Zusammenhang auch die künftige Master Data Governance- mit der S/4HANA MDG: Der Mehrwert von S/4HANA ist auch definiert durch eine hohe Qualität der Stammdaten. MDG deckt die steigenden Anforderungen an Governance und Compliance ab und ist eine international einsetzbare und standardisierte Plattform zur zentralen Anlage, Pflege, Verwaltung, Verteilung und Konsolidierung aller relevanten Stammdaten – unabhängig davon, ob die angeschlossenen Zielsysteme SAP- oder Non-SAP-Systeme sind. Wie kann Ihr Unternehmen das MDG nutzen und welche Voraussetzungen sind dazu notwendig? Um dies kompakt und kostengünstig zu erfahren, empfehle ich den Workshop „2100-MDG“ der T4T (4 Std / 200,– EUR) – fordern Sie gern bei uns die aktuellen Termine und Anmeldemodalitäten an.

E(nhancements) – Um die Freiheitsgrade in der Systembereitstellung nicht einzuschränken, beachten Sie bitte BLOG 18 -Wie kann oder sollte mit dem Begriff des „SAP Standard“ im S/4HANA umgegangen werden, und warum ist es wichtig, das festzulegen?

F(orms) – Ich würde heute die folgenden Prinzipien für Formulare vorschlagen:

• Es wird eine einheitliche, intern einfach zu betreuende Formularentwicklungstechnologie, wie z.B. Adobe Forms verwendet.
• Für nur intern genutzte Formulare (z.B. in der Produktion oder Instandhaltung) wird rein auf die Inhalte und die effiziente Nutzung und nicht auf das Layout fokussiert.
• Für extern verwendete Formulare wird ein einheitliches von der zuständigen Abteilung definiertes C(orporate) I(dentity) Layout einmal eingerichtet und einheitlich in allen Formularen verwendet.

W(orkflows) – im S/4HANA hat sich in diesem Bereich sehr viel getan:

Beschaffungs-Workflows: Obwohl es SAP Business Workflow bereits seit dem ERP SAP R/3 gibt, ist das Thema im Zuge der Digitalisierung und Prozessautomatisierung wieder in den Fokus von Unternehmen gerückt. Gleichzeitig hat SAP im Rahmen ihrer S/4HANA-Strategie die Workflow-Komponente im Bereich Einkauf erweitert und erneuert. Zusätzlich zu den bestehenden Release-Optionen und -Verfahren (die weiterhin unterstützt werden) hat SAP den sogenannten flexiblen Workflow entwickelt. Hier ist es möglich, Freigabeprozesse auf Basis eines leicht anpassbaren Regelwerks für die verschiedenen Objekttypen im Einkauf zu definieren. Auch die Umstellung der GUI-Technologie hin zu SAP Fiori hat die Arbeit mit SAP Business Workflow erleichtert.
Eine sehr kompakte Einführung in die neuen Workflows bietet der Kurs „2100-WFMM“ der T4T (3 Std / 150,– EUR) – fordern Sie gern bei uns die aktuellen Termine und Anmeldemodalitäten an.

Vertriebsworkflows: Im Bereich Einkauf (MM) wird SAP Business Workflow von den meisten Unternehmen bereits intensiv genutzt. Im Bereich Sales and Distribution (SD) hat der Workflow längst ein Schattendasein geführt. Mit Ausnahme der Freigabe von Gutschrifts- und Lastschriftanträgen haben Unternehmen vor allem maßgeschneiderte Workflow-Implementierungen eingesetzt. Mit der Einführung von S/4HANA hat SAP es jedoch ermöglicht, zusätzliche Standard-Workflow-Szenarien zu definieren. Über die flexiblen Workflows ist es nun auch möglich, Workflows für Aufträge und Angebote schnell und einfach zu konfigurieren und so die Prozesse zu automatisieren und zu digitalisieren.
Eine sehr kompakte Einführung in die neuen Workflows bietet der Kurs „2100-WFSD“ der T4T (3 Std / 150,– EUR) – fordern Sie gern bei uns die aktuellen Termine und Anmeldemodalitäten an.

Abschließender Akzeptanztest: Wenn Sie in den bisherigen Integrationstests die Accelerated Testing Umgebung verwendet haben, sind Sie für den abschließenden Akzeptanztest aufgrund der 100%igen Wiederverwendbarkeit und der integrierten Übersetzungsmöglichkeiten bestens gerüstet. Details entnehmen Sie bitte BLOG 19 – Was ist die Accelerated Testing Environment, und wie bereite ich diese vor?

Zugrundeliegende Testprinzipien des abschließenden Akzeptanztests während der Realisierung sollten sein:

• Es wird e2e alles getestet inkl. RICEFW, Berechtigungen, Prozess- und Anwenderdokumentation sowie Ein- und Ausgabe Devices.
• Es wird alles in allen relevanten Sprachen getestet.
• Die Systembedienung erfolgt ausschließlich durch das Business und NICHT durch einen Berater.
• Der Test erfolgt auf Basis eines Komplettloads der Datenmigration – dieser sollte die finale Produktivqualität haben.
• Das Business bestimmt, was getestet wird – es sollten allerdings nur real existierende Testfälle sein.
• Jedes erfolgreich absolvierte Testskript wird formal von den Business-Ownern abgenommen.
• Das Incident-Handling erfolgt analog zu dem für den Produktivbetrieb geplantem, bzw. unter Nutzung desselben.