S/4HANA-Migration im Mittelstand
Umstieg auf S/4HANA - Tipps aus der Praxis
- Grundlagen des Migrationsprojekts
- Die passenden Teams aufbauen
- Das richtige Projektmanagement
Foto: SAP SE
Der Druck auf SAP-Kunden ist weg. SAPSAP hat sich den Wünschen der Anwender gebeugt und die Wartung für die SAP Business Suite 7 bis 2027 verlängert. Also ist keine Eile mehr geboten für die Migration auf S/4HANA. Das kommt den rund zwei Dritteln aller Unternehmen zugute, die den Umstieg noch nicht vollzogen haben. Alles zu SAP auf CIO.de
Eine trügerische Atempause. Denn wer das Thema jetzt noch weiter aufschiebt, tut sich trotz der entzerrten Terminlage und auch in der aktuellen ökonomischen Lage keinen Gefallen. Es geht um mehr als eine lästige und teure technische Umstellung: S/4HANA kann mit der richtigen Strategie zu einem Nukleus für die konsequente Digitalisierung von Unternehmensstrukturen werden. Das hilft Unternehmen auf der Kostenseite, aber es kann auch unmittelbaren Kundennutzen schaffen – etwa, um global operierenden Kunden auch global durchgängige Services anbieten zu können.
Lesetipp: Der S/4HANA-Zug nimmt Fahrt auf - CEO Klein im Gespräch
Was aber gerade in Zeiten gekürzter Budgets und beschränkter personeller Ressourcen bleibt, ist die Sorge vor einem ausufernden Migrationsprojekt. Viele Verantwortliche haben Bedenken in Sachen Komplexität, Kosten, Business Continuity und langfristiger strategischer Ausrichtung in der IT.
Eine pragmatische Migration innerhalb eines Geschäftsjahres ist für einen mittelständischen Konzern dennoch ohne Weiteres möglich – das haben wir bei EagleBurgmann bewiesen und in zehn Monaten den Umstieg bewältigt. Allerdings müssen dafür die Voraussetzungen und die strategische Ausrichtung stimmen. Die folgenden vier Faktoren haben sich als entscheidend erwiesen.
Alles auf den Prüfstand mit Blick in die Zukunft
Mittelständische Industrieunternehmen können vor erheblichen Herausforderungen stehen, was die Digitalisierung und Automatisierung von Kernprozessen angeht. Diese Aufgaben sind mittelfristig mit den bestehenden Architekturen oft nicht zu bewältigen. Erst recht nicht, wenn Standorte global integriert und harmonisiert werden sollen.
Die Migration auf S/4HANA nur als Releasewechsel zu verstehen, greift dabei viel zu kurz. Sie eröffnet die Möglichkeit, Prozesse nachhaltig zu verbessern und sowohl aktuelle als auch zukünftige Business-Anforderungen abzubilden. Dafür braucht es die Unterstützung aus dem Management.
Eine weitere Chance ist, altes Customizing und Workarounds auf den Prüfstand zu stellen. Eine Entschlackung und ein Rückbau zum Standard – wo immer möglich – kann nur positiv sein. Wichtig ist, dass dieser Rückbau im direkten und ständigen Dialog mit den Fachabteilungen erfolgt. Diejenigen, die mit den Systemen arbeiten, müssen die Veränderungen kennen und sie aktiv unterstützen.
Die Anwender ins Boot holen
Ein externer Provider nimmt dem Unternehmen die Migration quasi als "Generalunternehmer" ab. Dieses Konzept hat gerade für den Mittelstand mit seinen begrenzten Ressourcen eine Menge Charme – und einige Nachteile. Denn für ein solches Projekt muss die Agenda des Unternehmens selbst maßgeblich sein, nicht die des Dienstleisters. Erfolg verspricht ein internes, starkes Team aus IT und Business, das den Prozess treibt und die Verantwortung teilt – also ein duales Modell.
Es stellt sicher, dass die einmal festgelegten Ziele nicht aus dem Blick geraten, und dass strategische Nachjustierungen frühzeitig vorgenommen werden können. Dieses Team muss gut zusammenarbeiten und schon im Vorfeld gut trainiert werden. Natürlich geht es nicht ohne externe Partner. Wo immer möglich, empfiehlt es sich, in erster Linie das interne Team coachen zu lassen und für die Aufgaben externe Hilfe einzubeziehen, wo intern noch kein Wissen und Erfahrungen vorhanden sind.
Pragmatisches, stringentes Projektmanagement
Oft bleiben S/4HANA-Projekte bereits bei der Entscheidung zwischen Brown- und Greenfield-Ansatz ein erstes Mal stecken. Hier bewährt sich – wie in der ganzen Projektplanung – eine gesunde Portion Pragmatismus. Ein hybrider Ansatz zwischen den beiden Ansätzen ist ein Kompromiss, der genügend Spielraum für die Zukunft offenhält und trotzdem eine solide Zeit- und Budgetplanung zulässt.
Unrealistische Maximalziele können zu einem "unendlichen" Projekt werden, das mehr Probleme schafft, als es löst. Bewährt hat sich eine "Timebox"-Methode: Innerhalb eines festgeschriebenen Zeitrahmens wird nur der Scope (Umfang) an Prozessverbesserung und Systemstandardisierung eingeplant, der auch realistisch umgesetzt werden kann. Wenn Engpässe auftreten, verlängert sich nicht die Projektdauer, sondern der Projekt-Scope muss angepasst werden.
- 1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen. - 2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia. - 3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv. - 4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt. - 5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet. - 6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann. - 7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht. - 8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software. - 9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist. - 10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat. - 11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3. - 12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen. - 13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren. - 14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes. - 15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden. - 15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.
Dem Unternehmen ist mit mehreren kürzeren, aber ausführbaren Projekten mehr geholfen als mit langfristigen Projekten, deren Benefit der Organisation erst viel später zugutekommt. Die Erfahrung hat gezeigt, dass eine Reifegradprüfung vor Projektstart unerlässlich ist. Nur Projekte mit klarem Scope, klarem Ziel und einer fest definierten Planung werden gestartet. Das sichert den Projekterfolg und damit die Umsetzung von längerfristigen Roadmaps ab.
Migration in Angriff nehmen
Der Markt für die erforderlichen Dienstleistungen mag zwar kurzfristig wieder etwas entzerrt sein, aber die meisten Unternehmen – einschließlich großer Konzerne – haben die Umstellung auf S/4HANA noch vor sich. Die Provider und Berater können sich ihre Kunden aussuchen. Dabei kann ein mittelständisches Unternehmen Gefahr laufen, entweder auf die lange Bank geschoben oder von einem B-Team betreut zu werden. (bw)