S/4HANA-Migration bei Banken: Warum die Wahl zwischen Brownfield, Greenfield und Selective Data Transition zur Kostenfrage wird
Für ECC 6.0-Systeme endet die Mainstream-Wartung zum 31.12.2027. Eine Verlängerung bis 2030 ist möglich, kostet aber einen Aufschlag von 2 Prozentpunkten auf die Wartungsbasis – in der Praxis bedeutet das 9 bis 12 % höhere Gesamtkosten. Ab 2031 greift dann eine Customer-Specific Maintenance: keine Legal-Changes-Updates mehr, keine Security-Garantie, keine SLAs. Banken, die die Migration jetzt nicht planen, zahlen also so oder so drauf.
Die eigentliche Frage ist deshalb nicht, ob migriert wird, sondern wie. Und diese Entscheidung hat direkten Einfluss auf Projektkosten, Laufzeit und die Qualität der resultierenden Prozesslandschaft.
Ausgangslage: Mehr als ein technisches Upgrade
Institute, die vor der S/4HANA-Migration stehen, haben meist mehrere offene Baustellen gleichzeitig. Die IT-Architektur ist über Jahre gewachsen und entsprechend unübersichtlich. Datenvolumina sind angestiegen, Berechtigungskonzepte haben mindestens Optimierungspotenzial, und die daraus resultierenden Lizenzkosten liegen oft höher als nötig. Wer diese Baustellen bei der Migration ignoriert und nur die Systemversion wechselt, löst keine Probleme. Er nimmt sie einfach mit in die neue Systemgeneration.
Eine saubere Migrationsvorbereitung deckt entsprechend mehr ab als ein Technik-Upgrade:
- Bewertung des Business Case,
- Auswahl des passenden Deployment-Modells,
- Optimierung der Lizenzierung,
- Validierung der Infrastrukturparameter und
- Definition der Zielarchitektur.
Drei Migrationspfade
SAP-Migrationsstrategien bewegen sich zwischen zwei Polen.
Bei der Systemkonversion (Brownfield) werden bestehende Customizings vollständig übernommen, eine Prozessneugestaltung findet kaum statt. Der Umstellungsaufwand ist gering, dafür wandern ineffiziente oder veraltete Prozesse unverändert mit.
Bei der Neuimplementierung (Greenfield) wird das System komplett neu aufgesetzt, orientiert an SAP Best Practices, mit minimalem Prozess-Reuse. Das bringt maximale Standardnähe (Stichwort „Clean Core“), aber auch den höchsten Aufwand und das höchste Umstellungsrisiko.
Dazwischen liegt die Selective Data Transition (auch Bluefield), in zwei Varianten: Shell Conversion (überwiegend Brownfield, über 50 % Reuse (Wiederverwendung), automatisiert) und Mix & Match (überwiegend Greenfield, unter 50 % Reuse, teils manuell).
Brownfield spart kurzfristig Aufwand, zementiert aber bestehende Ineffizienzen. Greenfield bietet maximale Standardnähe, verursacht aber den höchsten Umstellungsaufwand. Aus der Projekterfahrung liegt der wirtschaftliche Sweet Spot deshalb häufig im Bluefield-Bereich- eine kosteneffiziente Lösung nah am Ist-Zustand, mit gezielter Prozessbereinigung an den Stellen, an denen sie sich lohnt.
Transformationspfad im SAP Banking: Nicht jedes Modul wird nur umgestellt
Bei Banken ist die Migration von ECC auf S/4HANA häufig mehr als eine technische Konversion: Bestehende Module werden auf neue SAP-Produkte überführt oder durch erweiterte Nachfolger ersetzt. Entsprechend hoch sind die Abhängigkeiten zwischen den Modulen, zu Nachbarprojekten und zu den vielen individuellen Schnittstellen, hinzu kommen spezifische Konfigurationen und umfangreiche Modifikationen. Die Kehrseite: Die technische Transformation lässt sich nutzen, um Prozesse zu verbessern, Effizienz und Qualität zu steigern und vor allem die Kreditprozesse weiter zu digitalisieren.
- SEM Banking: eine fachliche Herausforderung. SEM Banking ist in der Regel tief in Gesamtbanksteuerung, Deckungsbeitragsrechnung und aufsichtsrechtliche Berichterstattung eingebettet. Die Herausforderung ist deshalb weniger technischer als fachlicher Natur, und für die einzelnen SEM-Komponenten sind strategische Architekturentscheidungen nötig: Drittanbieterlösung oder modulweise Ablösung durch native S/4HANA-Module. Bei der zweiten Variante übernimmt SAP PaPM (Profitability and Performance Management) die Aufgaben des Profit Analyzers. Große Teile des Risk Analyzers fließen in SAP TRM (Treasury and Risk Management), etwa Value-at-Risk und Sensitivitäten im Market Risk Analyzer oder die Limitüberwachung im Credit Risk Analyzer. Funktionen des Strategy Analyzers lassen sich durch SAP Analytics Cloud für Planung und Strategie ersetzen. Hilfreich zu wissen: TRM und SEM Banking nutzen historisch über den Market Risk Analyzer denselben finanzmathematischen Rechenkern (Barwertberechnungen, Volatilitäten, Value-at-Risk). Entscheidend ist daher, welche bisherigen Funktionalitäten sich in die TRM Analyzer überführen lassen.
- CFM: überschaubarer Aufwand. Für Eigengeschäfte, die in SAP CFM abgebildet sind, werden keine größeren Veränderungen erwartet. Die Funktionen bleiben im Transaction Manager von SAP TRM verfügbar, CFM wird per System Conversion überführt, vorhandene Individualisierungen werden analysiert und bei Bedarf angepasst. Eine Umstellung auf Fiori-Apps ist möglich.
- BCA: Wechsel auf Transactional Banking prüfen. SAP BCA wurde zwar auf S/4HANA gehoben, SAP Fioneer hat die Weiterentwicklung des Moduls aber eingestellt. Ein Wechsel auf SAP Transactional Banking (TRBK) sollte deshalb dringend geprüft werden. TRBK bietet zusätzliche Funktionen im Postenmanagement (Regelwerk), komplexe Dispositionsregeln, ein Master Contract Management für Rahmenverträge (unter anderem mit Cash Pooling, Kompensation, Fazilitäten und Verbundabschluss) sowie weit über 1.000 Business Add-Ins. Damit lassen sich mit hoher Wahrscheinlichkeit zahlreiche Eigenentwicklungen und Modifikationen ablösen. Zum Projektstart empfiehlt sich eine Bestandsaufnahme der Eigenentwicklungen und Schnittstellen in BCA samt Abgleich der Anforderungen mit den TRBK-Standardfunktionen.
- CML und CMS: Sicherheitenverwaltung als Knackpunkt. Für die CML-Darlehensfunktionen ergeben sich aus dem Wechsel auf S/4HANA keine direkten Anpassungserfordernisse. Anpassungen sind aber im Produkt-Customizing und bei den Berechtigungsrollen nötig, weil künftig SAP CMS zum Einsatz kommt: Die bisherige Sicherheitenverwaltung in CML steht in S/4HANA nicht mehr zur Verfügung. CMS muss eingerichtet und die Daten müssen migriert werden. Zusätzlich sind alle Funktionen anzupassen, die lesend oder schreibend auf die Sicherheitenverwaltung zugreifen, etwa Deckungsregister, Korrespondenz, Add-ons, Reporting und Eigenentwicklungen. Im Gegenzug bildet CMS Sicherheiten umfangreicher ab und verteilt sie flexibler, was eine intensive Einbindung von Kreditrisikosteuerung und Meldewesen erfordert. Unabhängig davon sollte der reibungslose Ablauf elementarer Anwendungen wie Wertberichtigungen, Rating und Refinanzierungsregister validiert werden.
- Complex Loans (CL): neue Datenstruktur. Die CML-Erweiterung für Complex Loans kann die Bearbeitung und Verwaltung von Investitions-, Auslands- und Konsortialfinanzierungen verbessern. Sie führt neue Datenentitäten ein: die Finanzierung als übergeordnetes Objekt, das alle Tranchen und Ziehungen aggregiert, die Tranche als Kreditlinie mit eigenem Volumen und eigener Laufzeit, die Ziehung als konkrete Inanspruchnahme einer Tranche sowie den Covenant mit Prüflogik und Eskalationsprozess für vertragliche Auflagen.
Über alle Module hinweg steckt vor allem bei TRBK und CML/CMS Potenzial, Eigenentwicklungen in den Standard zurückzuholen. Genau deshalb lohnt es sich, Bestand und Prozesse vor der Wahl des Migrationspfads genau zu prüfen.
Wie die Entscheidung objektiviert wird
Der SAP Readiness Check zeigt, was sich im System durch die Transformation ändert. Was vorher optimiert werden sollte, damit die Migration selbst günstiger und die Zielarchitektur schlanker wird, beantwortet er nicht. Hier setzt msg.FIT an.
Die Nutzungsanalyse läuft ohne Systemneustart, über die Auswertung von SCMON- und SUSG-Protokolldaten. So lässt sich erkennen, welche Transaktionen, Customizings und Reports tatsächlich verwendet werden – und welche nur Ballast sind, der sonst unnötig mitmigriert würde.
Die Berechtigungs- und Lizenzanalyse deckt SoD-Konflikte auf sowie inaktive oder falsch zugeordnete Lizenzen. Weil SAP mit S/4HANA auf ein neues, Authorization-basiertes Lizenzmodell umstellt, ist das nicht nur ein Compliance-Thema, sondern ein direkter Kostenhebel.
Bei der Analyse der Eigenentwicklungen wird geprüft, welche Entwicklungen nie produktiv genutzt wurden oder ob deren Funktion inzwischen im Standard abgedeckt ist. Auch hier steckt meist Einsparpotenzial.
Aus diesen drei Ebenen entsteht am Ende keine reine Bestandsaufnahme, sondern eine Empfehlung für Migrationsstrategie und Roadmap. Ziel ist es, den Explore- und Realize-Aufwand zu reduzieren, bevor er entsteht, statt ihn im laufenden Projekt nachträglich zu korrigieren.
Wissen Sie schon, welche Ihrer SAP-Prozesse eine Migration wert sind – und welche Sie besser hinter sich lassen, bevor die Wartung 2027 ausläuft?
Wenn Sie darauf noch keine klare Antwort haben, lohnt sich ein Gespräch. Wir bringen keine Blaupause mit, sondern einen Blick von außen auf genau die Stellen, an denen sich Ihre S/4HANA-Migration lohnt oder verzögert.
Projektvorgehen: Von der Kick-off-Analyse zur Empfehlung
Die zugrunde liegende Methodik läuft in mehreren Schritten. Am Anfang stehen Projektinitiierung und Abstimmung von Governance, Rollen und Scope. Es folgt die Analyse über Stakeholder-Interviews und die Identifikation projektrelevanter Einflussfaktoren wie Unternehmenswachstum, neue Geschäftsfelder oder Parallelprojekte. Darauf baut die strategische IT-Planung auf: Systembewertung mittels Readiness Check und msg.FIT, Dokumentation des Ist-Zustands. Aus Scoping und Aktionsplan – mit Workstreams für Prozesse, IT-Architektur, Lizenzen, Projektplanung, Aufwand und Kosten – entsteht schließlich ein konsolidierter Abschlussbericht mit Roadmap, kritischem Pfad, Risiken und konkreten Handlungsempfehlungen.
Der strukturierte Ablauf stellt sicher, dass die Migrationsentscheidung auf einer belegten Ist-Bewertung beruht, nicht auf einer pauschalen Präferenz für Greenfield oder Brownfield.
Fazit
Die Wahl der S/4HANA-Migrationsstrategie ist keine rein technische Entscheidung. Sie hängt vom individuellen Zustand der bestehenden Systemlandschaft ab: Customizing-Tiefe, Berechtigungsstruktur und Lizenzsituation bestimmen, wie viel Reuse wirtschaftlich sinnvoll ist. Institute, die diese Faktoren vor der Entscheidung systematisch erheben, verschaffen sich damit die Grundlage, um zwischen den drei Pfaden objektiv entscheiden zu können, statt sich pauschal für Brownfield oder Greenfield festzulegen, bevor der eigene Ist-Zustand überhaupt bekannt ist.
