S/4HANA Migration im Mittelstand richtig planen

Die S/4HANA Migration im Mittelstand beginnt selten auf einer grünen Wiese. Meist laufen über das bestehende ERP Auftragsabwicklung, Produktion, Einkauf, Lager, Finanzwesen und Reporting - ergänzt durch Eigenentwicklungen, angebundene Fachsysteme und historisch gewachsene Berechtigungen. Genau diese gewachsene Landschaft entscheidet darüber, ob die Umstellung planbar bleibt oder kurz vor dem Go-Live zu einem Risiko für den laufenden Betrieb wird.

Für mittelständische Unternehmen ist S/4HANA daher kein reines Technologieprojekt. Es ist ein Eingriff in Prozesse, Datenverantwortung, Schnittstellen und Steuerungsmechanismen. Wer die Migration auf die technische Systemumstellung reduziert, erkennt kritische Abhängigkeiten häufig erst in der Test- oder Cutover-Phase. Dann sind Zeitfenster knapp, Entscheidungen teuer und die Belastung für Fachbereiche unnötig hoch.

Die richtige Migrationsroute folgt der Ausgangslage

Am Anfang steht eine Grundentscheidung: Soll das bestehende System technisch nach S/4HANA überführt werden, werden Prozesse im Rahmen einer selektiven Transformation gezielt neu gestaltet oder wird ein neues System aufgesetzt? Die Begriffe Brownfield, Selective Data Transition und Greenfield beschreiben dabei unterschiedliche Wege, nicht unterschiedliche Qualitätsstufen.

Ein Brownfield-Ansatz kann sinnvoll sein, wenn etablierte Prozesse weitgehend erhalten bleiben sollen, die Datenqualität belastbar ist und kundeneigene Erweiterungen kontrollierbar dokumentiert sind. Er reduziert den fachlichen Umstellungsumfang, übernimmt aber auch einen Teil der bestehenden Komplexität. Ein Greenfield-Ansatz schafft mehr Raum für Prozessharmonisierung und ein neues Rollen- oder Datenmodell. Dafür steigen fachlicher Abstimmungsbedarf, Change-Aufwand und das Risiko, bewährte betriebliche Besonderheiten zu übersehen.

Die selektive Transformation liegt zwischen beiden Ansätzen. Sie kann beispielsweise dann passen, wenn Gesellschaften konsolidiert, Altdaten bereinigt oder einzelne Prozesse neu aufgesetzt werden sollen. Der Ansatz ist jedoch kein einfacher Kompromiss: Gerade Auswahlregeln für Daten, Belegketten und Abstimmungslogiken müssen fachlich und technisch präzise definiert werden.

Die entscheidende Frage lautet daher nicht: Welcher Ansatz ist modern? Sondern: Welche Ziele müssen mit vertretbarem Risiko erreicht werden? Dazu gehören der Umfang notwendiger Prozessänderungen, die Lebensdauer des heutigen ECC-Systems, der Zustand der Stammdaten, die Integrationsdichte und die verfügbare Kapazität in den Fachbereichen.

Vorprojekt: Transparenz schafft steuerbare Entscheidungen

Ein belastbares Vorprojekt liefert keine Folien mit allgemeinen Handlungsempfehlungen, sondern eine prüfbare Entscheidungsbasis. Dazu gehören eine System- und Schnittstelleninventur, eine Bewertung der Eigenentwicklungen, eine Analyse kritischer Geschäftsprozesse sowie eine erste Einordnung von Datenqualität und Archivierungsbedarf.

Besondere Aufmerksamkeit verdienen Schnittstellen. Im Mittelstand sind häufig EDI-Anbindungen, Lager- oder Produktionssysteme, Zollsoftware, Bankenkommunikation, BI-Lösungen und branchenspezifische Anwendungen an das ERP gekoppelt. Nicht jede Schnittstelle ist technisch anspruchsvoll. Kritisch wird sie, wenn ihre fachliche Bedeutung, ihr Datenobjekt oder ihr verantwortlicher Ansprechpartner unklar sind. Eine Schnittstellenliste ohne Priorisierung hilft im Go-Live-Fall nur begrenzt.

Auch die Eigenentwicklungen sollten nicht pauschal als Altlast behandelt werden. Manche Erweiterungen bilden tatsächlich wettbewerbsrelevante Abläufe ab, andere kompensieren nur historische Prozessbrüche. Für jede relevante Entwicklung braucht es eine nachvollziehbare Entscheidung: übernehmen, anpassen, durch Standardfunktion ersetzen oder stilllegen. Diese Entscheidungen gehören früh in die Roadmap, weil sie Architektur, Tests und Schulungsaufwand beeinflussen.

Ein Quick Check oder strukturierter Workshop kann diese Transparenz in kurzer Zeit herstellen, wenn IT, Fachbereiche, Prozessverantwortliche und gegebenenfalls Informationssicherheit gemeinsam auf die kritischen Objekte schauen. Das Ergebnis sollte ein priorisierter Maßnahmenplan sein - mit klaren Annahmen, offenen Punkten, Verantwortlichkeiten und einer realistischen Grobplanung.

Datenmigration ist Fachaufgabe und technische Disziplin

Stammdatenprobleme werden in S/4HANA-Projekten oft zu spät sichtbar. Dubletten bei Geschäftspartnern, uneinheitliche Materialklassifikationen, unvollständige Steuerdaten oder inkonsistente Organisationseinheiten lassen sich nicht durch einen technischen Migrationslauf lösen. Die Transformation macht Datenfehler häufig sichtbarer, weil neue Datenmodelle, Prüfungen und Prozessketten genauer greifen.

Deshalb braucht die Datenmigration eine fachlich verantwortete Governance. Für kritische Datenobjekte sollte feststehen, wer Qualität bewertet, wer Bereinigungsregeln freigibt und wer Abweichungen vor dem Go-Live akzeptieren darf. Besonders relevant sind Geschäftspartnerdaten, offene Posten, Material- und Stücklistendaten, Preis- und Konditionsdaten sowie historische Belege, die für Auskunfts-, Prüfungs- oder Nachweispflichten benötigt werden.

Nicht alle Daten müssen in gleicher Tiefe migriert werden. Es kann wirtschaftlich sinnvoll sein, operative Daten vollständig zu übernehmen und ältere Bewegungsdaten revisionssicher verfügbar zu halten, ohne sie in das neue Produktivsystem zu übertragen. Diese Entscheidung hängt von Reporting-Anforderungen, Betriebsmodellen, Aufbewahrungspflichten und der tatsächlichen Nutzung historischer Daten ab. Wichtig ist, dass die Auskunftsfähigkeit nach dem Go-Live konkret nachgewiesen wird.

Testmanagement entscheidet über die Betriebsstabilität

Viele Projekte testen technische Funktionen sorgfältig, aber Geschäftsprozesse nur fragmentiert. Ein einzelner erfolgreich gebuchter Auftrag belegt noch nicht, dass der gesamte Order-to-Cash-Prozess funktioniert. Erst wenn Auftrag, Verfügbarkeit, Lieferung, Faktura, Buchung, Nachrichtenaustausch und Reporting zusammen betrachtet werden, treten fehlerhafte Übergaben und Berechtigungsprobleme zuverlässig hervor.

Ein wirksames Testmanagement unterscheidet daher zwischen technischen Tests, Integrationstests, fachlichen End-to-End-Tests, Migrationstests, Berechtigungstests und der Anwenderabnahme. Für jeden Testzyklus müssen Umfang, Testdaten, Verantwortliche, Eintritts- und Austrittskriterien sowie ein belastbarer Umgang mit Defects festgelegt sein. Kritische Fehler brauchen nicht nur eine technische Lösung, sondern auch eine Bewertung ihrer Auswirkung auf Geschäftsvorfälle und Cutover-Termine.

Die Auswahl der Testfälle sollte risikobasiert erfolgen. Besonders hohe Priorität haben Prozesse mit direkter Auswirkung auf Umsatz, Zahlungsfähigkeit, Produktion, Versorgungssicherheit oder regulatorisches Reporting. In einem Großhandel können das EDI-Aufträge und Preisfindung sein, in der Energieversorgung Marktkommunikation und Abrechnung, in Chemie oder Life Sciences Chargenrückverfolgbarkeit und Freigabeprozesse.

Der Cutover braucht Führung, nicht nur einen Terminplan

Der Cutover ist die Phase, in der das Projekt zur Betriebsaufgabe wird. Ein detaillierter Plan mit Aktivitäten, Zeitfenstern und technischen Jobs ist notwendig, reicht aber nicht aus. Ebenso wichtig sind eindeutige Entscheidungswege, ein abgestimmtes Eskalationsmodell und die Fähigkeit, den tatsächlichen Fortschritt objektiv zu bewerten.

Ein belastbarer Cutover-Plan beantwortet unter anderem: Welche Datenstände werden zu welchem Zeitpunkt eingefroren? Wer gibt die Migrationsläufe frei? Wie werden Salden, Bestände und offene Vorgänge abgestimmt? Welche Schnittstellen werden wann umgestellt? Welche Mindestkriterien müssen erfüllt sein, bevor produktive Buchungen möglich sind? Und was passiert, wenn ein Kriterium nicht erreicht wird?

Gerade bei begrenzten internen Ressourcen sollten fachliche Schlüsselpersonen nicht gleichzeitig für operative Tagesaufgaben, Tests, Freigaben und Hypercare eingeplant werden. Das führt zu vermeidbaren Engpässen. Ein realistisch aufgesetztes Projekt schützt die Verfügbarkeit dieser Personen und ergänzt sie bei Bedarf durch erfahrene Spezialisten für Teststeuerung, Datenmigration, Schnittstellen oder Cutover-Koordination.

Die Hypercare nach dem Go-Live sollte ebenfalls geplant werden. Dazu zählen ein priorisiertes Incident-Verfahren, tägliche Lagebilder, klar zugeordnete Lösungsverantwortung und Kennzahlen für kritische Prozessketten. Entscheidend ist nicht, dass in den ersten Tagen keine Störung auftritt. Entscheidend ist, dass Störungen schnell erkannt, fachlich eingeordnet und kontrolliert behoben werden.

Governance und Berechtigungen früh integrieren

S/4HANA verändert häufig Rollen, Anwendungen und Datenzugriffe. Berechtigungskonzepte dürfen deshalb nicht erst kurz vor der Produktivsetzung geprüft werden. Unklare Rollen führen entweder zu unnötig weitreichenden Zugriffen oder zu blockierten Arbeitsabläufen. Beides gefährdet den stabilen Betrieb.

Für relevante Rollen sollten Aufgaben, benötigte Transaktionen und Anwendungen, kritische Berechtigungskombinationen sowie Genehmigungswege dokumentiert sein. Werden sensible personenbezogene, finanzielle oder produktionsbezogene Daten verarbeitet, müssen Datenschutz, Informationssicherheit und gegebenenfalls regulatorische Anforderungen in die Projektgovernance eingebunden werden. Bei konkreten rechtlichen Einordnungen zu Datenschutz, NIS2 oder IT-Recht kann die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH ergänzend hinzugezogen werden.

Revisionssicheres Reporting entsteht dabei nicht allein durch ein neues System. Es setzt nachvollziehbare Datenflüsse, abgestimmte Verantwortlichkeiten, dokumentierte Kontrollen und belastbare Nachweise voraus. Wer diese Anforderungen in Design, Tests und Betriebsübergabe verankert, vermeidet aufwendige Nacharbeiten nach dem Go-Live.

S/4HANA-Migration pragmatisch absichern

Quteco unterstützt mittelständische Projektteams mit Quick Checks, Workshops und operativer Projektbegleitung bei der Einordnung von Migrationsrisiken, Testmanagement, Datenflussanalyse und Cutover-Planung. Im Fokus stehen nachvollziehbare Verantwortlichkeiten und ein Vorgehen, das zur vorhandenen Systemlandschaft und zum laufenden Betrieb passt.

Eine gute Migrationsentscheidung schafft vor allem Klarheit: darüber, was zwingend verändert werden muss, was bewusst erhalten bleibt und woran der Projekterfolg im Betrieb tatsächlich gemessen wird.