Zusammenfassung: Eine sorgfältige Planung und Vorbereitung, eine schrittweise Migration mit klaren Prioritäten, ein kontinuierliches Monitoring sowie Schulung und Einbindung der Mitarbeiter sind essentiell für eine erfolgreiche Implementierung von S/4HANA.
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:
- Projektvorbereitung -> abgeschlossen mit dem Project-Kick-Off Meeting (s. BLOG-Beitrag 26)
- Scoping & Prototyping -> abgeschlossen mit dem end-to-end (e2e) Prozess-Integrationstest (ohne RICEF und ohne angebundene Sub-Systeme) (s. BLOG-Beitrag 28)
- Realisierung -> abgeschlossen mit dem end-to-end (e2e) Akzeptanztest (inkl. RICEF und angebundenen Sub-Systemen) (s. BLOG-Beitrag 29)
- Implementierung -> abgeschlossen mit dem Go-Live und der vollständigen Übergabe des Systems an die Business-Owner respektive die operative Support Organisation (aktueller Beitrag: BLOG-Beitrag 30)
In diesem Beitrag geht es um die „Implementierung“.
Phase 4: Implementierung
Nachdem das System in der Realisierungsphase prozedural und funktional von den Prozessverantwortlichen oder Business-Ownern abgenommen wurde, kann es nun final implementiert werden. In dem Zusammenhang geht es meiner Erfahrung nach insbesondere um drei wichtige Tätigkeitsbereiche:
- Schulung der Endanwender
- Finalisierung und Umsetzung des Go-Live-Planes
- Planung und Organisation des Supports für den Produktionsanlauf
Schulung der Endanwender
Falls Sie meiner Empfehlung in dem Beitrag zur Erstellung der Anwenderdokumentation (s. BLOG-Beitrag 25) nachgekommen sind, sind Sie für die Schulung der Endanwender gut gerüstet, denn diese können sich weitestgehend eigenständig aus den auf Basis der Anwenderdokumentation mit überschaubaren aufwänden erstellbaren CBTs (Computer Based Trainings) schulen. Dies erleichtert insbesondere auch die Schulungsplanung, da keine separaten Ressourcen wie Räume und Trainer geplant werden müssen und auch die Terminplanung zur Durchführung der Schulungen ja entfallen kann. Es sollte lediglich nachgehalten werden, ob die Mitarbeitenden, die neu für sie relevanten CBTs abgearbeitet und trainiert haben. Dies können Sie in einem separaten LMS (Learning Management System) nachhalten oder die dafür im Autorentool normalerweise vorhandenen Funktionen nutzen.
Wenn Sie dann auch noch meiner Empfehlung für die Migration (s. BLOG-Beitrag 22) gefolgt sind, wird es Ihnen auch leichtfallen, den Usern eine Trainingsumgebung, welche mit dem realen Stammdatenbestand sowie zumindest einem Teil, der initial zu übernehmenden Bewegungsdaten gefüllt ist, zur Verfügung zu stellen. Meine Empfehlung ist, hier mit mehreren Mandanten zu arbeiten – einem Master, in dem die Daten einmal aufgebaut werden und der periodisch auf einen oder mehrere Mandanten (z.B. einen in gerade Wochen und einen zweiten in ungerade Wochen) kopiert wird, in welchen die User dann trainieren können. Den Testmandanten selbst für Trainings zu benutzen, würde ich nicht empfehlen, da dies zu ansonsten vermeidbaren zusätzlichen Komplexitäten führt.
Für im Schichtbetrieb der Produktion tätige Mitarbeitende, die im neuen System z.B. Eingaben an einem BDE-System machen müssen, haben sich besetzte Trainingsstationen in der Produktion bewährt, an denen diese vor oder nach Schichtende geschult werden.
Finalisierung und Umsetzung des Go-Live-Planes
Bei der Erstellung der Go-Live-Pläne habe ich mich immer von den folgenden Prinzipien leiten lassen und bin damit sehr gut gefahren – auch in sehr komplexen Umgebungen:
- Es sind alle Schritte, die technisch und organisatorisch relevant sind, in dem Plan enthalten. Insbesondere auch Tätigkeiten, wie z.B. das Aufräumen von Lagern und die Zeiträume der Parallelpflege von Stammdaten. Verantwortlichkeiten (Verantwortlich Durchführender und Accountable Manager) sind ebenso hinterlegt wie die vollständigen Abhängigkeiten der einzelnen Tasks untereinander. Ich habe in dem Zusammenhang sehr gute Erfahrungen mit dem Einsatz von MS-Project als Management-Tool für den Go-Live gemacht. Um die Planungen allen zugänglich zu machen und für Updates habe ich gute Erfahrungen mit Excel-Exporten gemacht. Mit dem richtigen Vorgehen kann man einen MS-Project-Plan gut 1:1 nach Excel exportieren. Eine Beispiel-Vorlage, anhand der Sie nachvollziehen können, was ich meine, finden Sie in meinem Digistore24: https://sapxp.ch/asap-ms-project-plans-digistore24/ in dem SAMPLE_Projektplan_Aktuell.mpp bzw. xlsx aus dem Projektplanungspaket. Für die Erstellung, die laufenden Updates des Go-Live-Planes sowie die Eskalation verzögerter Tätigkeiten ist ein dedizierter Go-Live-Manager verantwortlich. Falls das Go-Live über mehrere Standorte geht, ist es sehr zu empfehlen, neben dem übergreifend verantwortlichen Go-Live-Manager auch für jeden Standort einen dediziert für diesen verantwortlichen Go-Live-Manager zu nominieren.
- Alle Schritte zur Datenmigration einschl. aller Nachbereitungen werden schon evolutionär bei den vollständigen Testmigrationsdurchläufen komplettiert, einschl. Datenquelle, zu nutzender Funktion im Migrationswerkzeug und allen Vor und Nachbereitungen. Unter anderem deshalb ist es so wichtig, dass Sie meiner Empfehlung für die Migration (s. BLOG-Beitrag 22) folgen.
Schlussendlich sollte alles so dokumentiert sein, dass die Migration auch personenunabhängig (z.B. bei Ausfall eines wichtigen Mitglieds des Migrationsteams) ohne Zeitverlust fortgeführt werden kann. Verantwortlich für das Pflege und das Update aller Migrationsrelevanten Tasks in den Plan ist der Migrations-Team Lead oder Manager. - Im Rahmen des Go-Live wird KEINE physische Inventur der Lagerbestände gemacht, insbesondere werden die Bestände nicht in das neue System per physischer Inventur „gezählt“ – das kann nur daneben gehen (auch wenn es scheinbar eine weit verbreitete Meinung ist, dass das ein „gutes“ Vorgehen sei). Es werden immer die Buchbestände dokumentiert, mit allen Mutationen maschinell in das neue System überführt. Nur so kann eine prüfungssichere Migration ohne unnötige Risiken durchgeführt werden. Falls es als notwendig erachtet wird, eine physische Inventur durchzuführen, kann diese entweder im Altsystem vor Beginn jeglicher Go-Live-Aktivitäten oder im Zielsystem nach dem vollständigen Abschluss des Go-Live durchgeführt werden. Nicht 1:1 von alt nach neu zu migrierende Bestände (z.B. WM-bedingt, weil neu Chargen- oder Seriennummern eingeführt werden oder auch weil Materialnummern gesplittet oder zusammengelegt werden) die nicht direkt problemlos auf den neuen Lagerort/Lagerplatz gebucht werden können, können auf einen separaten Migrationslagerort (in demselben Bewertungskreis) gebucht und von dort im Nachgang der Übernahme maschinell oder manuell auf den finalen neuen Lagerplatz/Lagerort gebucht werden. Dadurch ist sichergestellt, dass der für die Freigabe der Bestandsbuchungen notwendige Abgleich der buchhalterischen Bestandskonten zwischen Quell- und Zielsystem nicht unnötig verzögert wird.
- Legen Sie sehr viel Wert auf das detaillierte Umstellen der angebundenen Drittsysteme (Schnittstellen) vom alten auf das Neue System sowie die damit verbundenen Datenzustände und deren Lösung!
- Der Go-Live- und Cut-Over-Plan endet dann, wenn in allen wesentlichen Funktionen die ersten Aktivitäten erfolgreich im Zielsystem ausgeführt wurden. Dies sind insbesondere:
- Die Migration der Bestände und der erfolgreiche Abgleich der Bestandkonten (das ist DAS Go-Live-Kriterium, weil ab dann im neuen System gebucht wird)
- Der erste MRP-Lauf
- Der erste Zahllauf für Kreditoren
- Die Verarbeitung der letzten Bankauszüge aus der Vorperiode und die Übernahme der davon abhängigen offenen Posten der Debitoren
- Die Umbuchung sämtlicher Bestände auf den Migrationslagerorten (s.o.)
- Die vollständige Abarbeitung der noch im Altsystem (bzw. parallel) abzuschließenden Buchungen
- Die Migration der Hauptkonto-Abschlusssalden aus dem Altsystem
- Der erste Monatsabschluss
- Auch wenn es ausreichend ist, das gesamte Go-Live tagesgenau zu planen, sollte die „heiße“ Cut-Over-Phase, während der in der Regel keine Bestandbuchungen möglich sind, stundengenau geplant werden. Auch empfehle ich dringend vorzusehen, zumindest für diese „heiße“ Cut-Over-Phase einen Testdurchlauf als Generalprobe zu machen!
Planung und Organisation des Supports für den Produktionsanlauf
Ermitteln Sie frühzeitig den Supportbedarf, insbesondere vor Ort für die heiße Cut-Over-Phase wie auch für den Produktionsanlauf. Wenn Sie an mehreren Standorten gleichzeitig live gehen und im Mehrschichtbetrieb arbeiten, kann es sehr schnell sein, dass Sie, wenn sie eine Detailplanung erstellen, von der Vielzahl der benötigten Ressourcen überrascht sind. Planen Sie pro Standort, Schicht und Funktion, die Support benötigt, die Namen der jeweiligen Supporter und berücksichtigen Sie auch, dass es einen weiteren Level im Backend geben muss, der die gemeldeten Incidents, die nicht gleich vor Ort gelöst werden können, löst. Berücksichtigen Sie insbesondere auch die sprachlichen Aspekte: Wenn ein Großteil der vor-Ort-Supporter permanent einen Übersetzer neben sich benötigt, ist das nicht nur ressourcentreibend, sondern auch ineffektiv. Ich habe gute Erfahrungen damit gemacht, den Go-Live-Support so früh zu planen, dass die zusätzlich benötigten (lokalen) Berater auch den Integrations- und Akzeptanztest vor Ort unterstützen können und sich so auch gleichzeitig zum beiderseitigen Nutzen in die Spezifika der Prozesse und des Standortes in ihren Funktionen einarbeiten können. Wenn Sie Ihr neues System künftig von einem externen AMS-Dienstleister betreuen lassen, sollten Sie auch diesen als Ressourcenquelle für das Backend frühzeitig mit einbeziehen. Ich bin sogar der Ansicht, dass dieser die Incidents, die nach dem abgenommenen Akzeptanztest erfasst wurden und nicht direkt der Migration und dem Cut-Over zuzuordnen sind, bearbeiten sollte, um so von Anfang an die Bearbeitung der produktiven Tickets in der Hand zu haben.
Ähnlich verhält es sich mit dem Incident-Management-System, welches rechtzeitig identifiziert, ausgeprägt und genutzt werden sollte. Vielfach werden während des Projektes die Incidents in irgendeinem System, z.B. MS-Excel OP-Listen gemanagt und NICHT bereits das finale, im späteren produktiven Einsatz vorgesehene Incident-Management-System genutzt; die Gründe dafür scheinen vielfältig. Das ist meiner Ansicht nach allerdings ein fataler Fehler, denn dann …
- sind die Anwender, Key-User und meine interne Support Organisation nach definierten Regeln in die Abläufe des aktuell produktiven Incident-Management-Systems eingebunden und mit diesen und dessen Bedienung vertraut.
- erhöhe ich die Komplexität (unnötigerweise) ungemein, wenn ich während des Go-Live auch noch den Umstieg auf ein anderes oder gar die Einführung eines neuen Ticketsystems einplanen und leisten muss.
- müssen die Projektressourcen, die im Produktionsanlauf unterstützen, nicht über einen längeren Zeitraum mit dem Incident-Management parallel in zwei unterschiedlichen Systemen umgehen.
- trage ich, bei Verwendung desselben Ticketsystems nicht gelöste Tickets automatisch in den Produktivbetrieb vor (ob ich diese dort dann anders bewerte oder priorisiere, kann ja jederzeit entschieden werden).
Machen Sie also bitte diesen Fehler nicht und nutzen Sie spätestens im Akzeptanztest (besser schon in den Integrationstests) sowie den Anwenderschulungen ihr für den späteren produktiven Betrieb vorgesehenes Ticket-System zum Management aller auftretenden Incidents.
Denken Sie bitte unbedingt auch daran, sowohl für die heiße Cut-Over-Phase, wie auch für die ersten Wochen des Produktionsanlaufs in hoher Frequenz (anfangs täglich) Zeitfenster für Eskalations-Meetings mit den Prozessverantwortlichen, wie auch dem Lenkungsausschuss bzw. der Geschäftsführung zu planen und in den Kalendern einzustellen. Falls alles super glatt läuft und Sie einen „langweiligen Go-Live“ haben, weil Sie meine Empfehlungen aus diesem BLOG konsequent umgesetzt haben, können Sie überflüssige Meetings ja wieder absagen.
EPILOG
Mit diesem Beitrag ist der Zyklus der BLOG-Beiträge mit meinen erfahrungsbasierten Empfehlungen für eine auf den Best-Practice Prozessen basierte S/4HANA Implementierung aus meiner Sicht abgeschlossen. Mir ist bewusst, dass ich in vielen Beiträgen des BLOGs einfach erfahrungsbasierte Empfehlungen gegeben oder auch entsprechende Behauptungen aufgestellt habe. Das mag für den ein oder anderen unseriös oder arrogant erscheinen (würde mir auch so gehen) – ist aber überhaupt nicht so gemeint. Ich bin gern bereit, Ihnen den Hintergrund jeder Empfehlung und jeder Behauptung zu erläutern und diese zu verargumentieren. Wenn Sie daran Interesse oder auch Fragen zu einzelnen Vorgehensweisen oder Werkzeugen haben, nehmen Sie gern Kontakt mit mir auf!
Sehen Sie mir auch bitte nach, wenn ich bestimmte Aspekte übersehen oder bewusst nicht angesprochen habe. Da es das Ziel war, Sie an meinen Erfahrungen teilhaben zu lassen, habe ich natürlich auch nur über diese und das, was aus meiner Sicht wichtig ist, geschrieben.
Und natürlich freue ich mich auch über jede andere Art von Feedback, wie zum Beispiel dieses, welches mich am 09.09.2022 via LinkedIn erreichte:
„Dein Blog … hat mich echt weitergebracht. Herzlichen Dank! Ich bin Expertin für Prozessmanagement und bei vielen meiner Kunden läuft gerade die Umstellung auf SAP HANA. Ich bin bemüht, beide Sichten auf Prozesse zusammen zu bringen und so auf deinem Blog gelandet. Lass uns gern vernetzen und kennenlernen. Ich habe auch einen Blog und freue mich deshalb umso mehr, einen kompetenten Weggefährten getroffen zu haben. Viele Grüße S.“
ICH WÜNSCHE IHNEN AUF JEDEN FALL EINEN ERFOLGREICHEN VERLAUF IHRER S/4HANA IMPLEMENTEIRUNG UND DAS DIESE IN EINEM „BORING GO LIVE“ MÜNDET!
UND WENN SIE DIE WERKZEUGE AUS MEINEM DIGISTORE24 EINGESETZT HABEN, SOLLTE IHNEN DAS GANZE JA AUCH NOCH EFFEKTIV UND KOSTENGÜNSTIG GELUNGEN SEIN!
…und wenn es dann so war, vergessen Sie nicht, dies gebührend mit dem Projektteam zu feiern, das Geld dafür haben Sie dann ja im Projekt eingespart!