Der gewählte Ansatz sollte für alle verständlich festgehalten und kommuniziert werden.

Der Zeitplan und frühestmöglicher Go-Live Termin hängen ganz wesentlich vom aktuellen Kundensystem ab. Wurde dieses erst vor wenigen Jahren aufgesetzt ohne viele Eigenentwicklungen, mit geringem Funktionsumfang und mit sauberen Stammdaten so kann eine Transformation recht sportlich in 6-10 Monaten gelingen. Die Realität der meisten SAP-Kunden schaut jedoch anders aus, hier sind historisch gewachsene Systeme einzufangen und in das neue Korsett zu bringen.

Zeitpläne helfen, die Migration strukturiert abzuwickeln und dienen auch als Kommunikationsmittel. Die einzelnen Aufgaben sind insbesondere für die Durchführung des Go-Lives (Produktivsystem-Migration) möglichst detailliert zu dokumentieren und den Verantwortlichen zuzuweisen, um Abhängigkeiten und wichtige Zwischenschritte im Ablauf korrekt zu berücksichtigen. Wir empfehlen, insbesondere für kritische Phasen detaillierte Zeitpläne im Überblick zu erstellen und diese mit Aufgaben-Listen zu unterlegen, und dabei auch die Abhängigkeiten zu anderen Projekten wie z.B. Ablöse anderer bestehender Software-Lösungen im Auge zu behalten und sich mit diesen intensiv abzustimmen.

Besonderes Augenmerk ist auf die Planung des Go-Lives zu legen. Nach erfolgtem Go-Live ist ein ausreichender Hypercare-Support für die Fachabteilungen sicherzustellen. Wir empfehlen auch, mit SAP eine Bereitschaft zu vereinbaren, z.B. bei HANA-Datenbankproblemen während der Konvertierung. Wir empfehlen auch, vorab Notfallpläne und Backup-Lösungen zu erarbeiten, z.B. unter welcher Voraussetzung wird das ECC-Backup gezogen, welches unbedingt vorab zu erstellen ist, und was geschieht falls ein zentrales Projektmitglied überraschend ausfällt.

Je nach System-Ausgangssituation und Resultat der ersten Sandbox-Konvertierung wird eine erste Entscheidung über die Anzahl der Test-Konvertierungen getroffen, die sich auf die Projektdauer auswirkt. Testkonvertierungen reduzieren das Risiko von Fehlern bei der Produktivmigration signifikant und sorgen für ein eingespieltes Projektteam. In der Regel gibt es eine dreistufige Systemlandschaft mit Entwicklungs-, Test- und Produktivsystem. Daraus ergeben sich bereits zwei Testzyklen. Wir empfehlen, darüber hinaus mindestens zwei weitere Testzyklen durchzuführen, indem das ECC-Produktivsystem in eine Sandbox kopiert wird und darauf die Konvertierung auf S/4HANA eingeübt wird – so produktivnah wie möglich. Die Sandbox-Systeme werden in enger Abstimmung mit der Basis bzw. mit dem Basis-Outsourcing-Partner bereitgestellt.

Eine zentrale, für alle erreichbare Projektplattform erleichtert die Kommunikation und Bereitstellung von Testfiles, Schulungsunterlagen, und relevanter Dokumente. Wir empfehlen, nach Möglichkeit auf bestehende Strukturen zurückzugreifen wie z.B. SharePoint oder Intranet-Seiten.

Falls es ein bestehendes Ticket-System gibt, bietet es sich an, darin eine eigene Kategorie „S/4HANA Test Findings“ zu erstellen, damit User darin negative Testergebnisse aufnehmen können. So behält das Projektteam den Überblick, kann den Fortschritt tracken und auf dieser Grundlage entscheiden, ob das System und die Anwender bereit für den Go-Live sind.

Im Rahmen eines Testkonzepts wird definiert, wann welche Tests stattfinden und wie diese mit dem Gesamtprojektplan zusammenspielen.

Nach Möglichkeit wird auf bestehende Testszenarien und Testdokumentationen zurückgegriffen. Wir empfehlen, das Nutzerverhalten über einen längeren Zeitablauf im Produktivsystem zu tracken damit in den Testfällen die tatsächlich verwendeten Transaktionen, Reports, und Apps abgedeckt werden können.

Betreffend der Schulungen haben wir gute Erfahrungen mit Schulungsvideos gemacht, die z.B. mit einfachen Tools with Camtasia von TechSmith aufgezeichnet und auf der zentralen Projektplattform zur Verfügung gestellt werden können. Damit entfällt ein Großteil der Vor-Ort-Schulungen, und die User können den Trainings-Content zeitunabhängig abrufen, wann es ihnen passt.