SAP Carve-Outs: Eine Analyse der selektiven Unternehmenstrennung

Die fortschreitende Globalisierung und der damit verbundene Strukturwandel in der Unternehmenswelt haben dazu geführt, dass Fusionen, Übernahmen und insbesondere die Veräußerung von Geschäftsbereichen – sogenannte Carve-Outs – zu einer täglichen Realität im strategischen Management geworden sind. In einer hochgradig integrierten IT-Landschaft, die oft auf SAP-Systemen basiert, stellt ein Carve-Out eine der komplexesten technischen und organisatorischen Herausforderungen dar, denen sich ein Unternehmen stellen kann. SAP Carve-Outs sind weit mehr als einfache Datenextraktionen: Es handelt sich um die präzise, chirurgische Trennung von Geschäftseinheiten, die über Jahre hinweg prozessual und datentechnisch miteinander verwoben waren. Der Erfolg einer solchen Ausgliederung hängt maßgeblich davon ab, wie sauber die IT-Strukturen getrennt werden können, ohne den laufenden Betrieb der verbleibenden Organisation (Seller) zu stören. Gleichzeitig soll die volle Einsatzfähigkeit der neuen Einheit (NewCo/Buyer) ab dem ersten Tag sichergestellt werden.

Die grundlegende Richtung eines Carve-Out-Projekts wird durch das zugrunde liegende betriebswirtschaftliche Transaktionsmodell definiert. In der Praxis wird primär zwischen dem Asset Deal und dem Share Deal unterschieden, wobei beide Szenarien grundlegend unterschiedliche Anforderungen an die IT-Architektur und den Migrationsumfang stellen.

Der Asset Deal und seine IT-Fokussierung

Bei einem Asset Deal werden spezifische Vermögenswerte (Wirtschaftsgüter) eines Unternehmens einzeln an den Käufer übertragen. Aus rechtlicher Sicht bedeutet dies häufig, dass der Käufer nur für zukünftige Verbindlichkeiten ab dem Zeitpunkt des Vollzugs (Closing) verantwortlich ist. In der SAP-Welt führt dies dazu, dass der Fokus primär auf der Übertragung von Stammdaten und offenen Posten liegt, die für die Fortführung des operativen Geschäfts unerlässlich sind. Historische Transaktionsdaten werden in diesem Szenario oft nicht migriert, da die rechtliche Verantwortung für die Vergangenheit beim Verkäufer verbleibt. Dies kann die technische Komplexität reduzieren, erfordert jedoch eine sehr saubere Definition dessen, was als „operativ notwendig“ gilt.

Der Share Deal und die Anforderung der historischen Kontinuität

Im Gegensatz dazu steht der Share Deal, bei dem Geschäftsanteile an einer rechtlich bestehenden Einheit (z. B. einer GmbH) erworben werden. Hier übernimmt der Käufer die gesamte rechtliche Identität mit allen vergangenen, gegenwärtigen und zukünftigen Verpflichtungen. Für das SAP-Migrationsprojekt hat dies gravierende Folgen: Es muss in der Regel die vollständige historische Datenhistorie des betreffenden Buchungskreises migriert werden, um zukünftige Audits, steuerliche Prüfungen und gesetzliche Berichtspflichten erfüllen zu können. In diesem Kontext ist die Datenqualität und Vollständigkeit der Historie von höchster Priorität, da jede Lücke in der Dokumentation ein rechtliches Risiko für den Käufer darstellt.

Die Herausforderung der Teilung: Selektion auf Buchungskreisebene

Ein häufiges Szenario in gewachsenen Konzernstrukturen ist, dass ein zu veräußernder Geschäftsbereich keinen eigenen Buchungskreis im SAP-System besitzt, sondern lediglich ein Teil eines größeren Buchungskreises ist. In diesem Fall muss eine Trennung innerhalb des Buchungskreises erfolgen, was die Komplexität des Projekts exponentiell erhöht. Hierbei kommen tiefere Organisationseinheiten als Selektionskriterien zum Einsatz, primär Profit Center oder Segmente.

Profit Center dienen in SAP S/4HANA dazu, die interne Rentabilität von Verantwortungsbereichen abzubilden. Da nahezu jeder operative Beleg (z. B. in der Materialwirtschaft, im Vertrieb oder in der Kostenrechnung) direkt oder indirekt einem Profit Center zugeordnet ist, eignen sie sich hervorragend als Ankerpunkt für die Datenselektion. Segmente wiederum werden häufig aus Profit Centern abgeleitet und ermöglichen eine Berichterstattung nach internationalen Rechnungslegungsstandards wie IFRS oder US-GAAP.

Dies ermöglicht es, nicht nur die Bilanz und GuV zu trennen, sondern auch alle untergeordneten Stammdaten wie Anlagen, Kostenstellen, Innenaufträge etc. präzise zu identifizieren.

Technische Implikationen des „Partial Carve-Outs“

Wenn ein Teil eines Buchungskreises herausgeschnitten wird, müssen die integrierten Prozesse, die zuvor innerhalb einer legalen Einheit abliefen, in Intercompany-Beziehungen transformiert werden. Dies erfordert Anpassungen im Customizing und in der Stammdatenpflege, da die verbleibende Einheit des Verkäufers und die neue Einheit des Käufers nun wie externe Geschäftspartner agieren müssen. Ein besonderes Problem stellt hierbei der sogenannte Belegsplit dar. Dieser muss sicherstellen, dass Belege, die mehrere Segmente betreffen, korrekt aufgeteilt werden, um eine saldoneutrale Bilanz pro Segment zu gewährleisten.

Methodik der technischen Umsetzung: Von Clone and Delete bis Selektiver Migration

Für die technische Realisierung eines Carve-Outs stehen verschiedene Strategien zur Verfügung, deren Wahl massiv von den Parametern Zeit, Budget und Datensicherheit beeinflusst wird.

Es folgen zwei prominente Beispiele. Der „Clone and Delete“-Ansatz basiert auf der Erstellung einer vollständigen Systemkopie des Quellsystems. In der Kopie werden anschließend alle Daten und Konfigurationen gelöscht, die nicht zum Umfang der Transaktion gehören.

• Vorteile: Schnelle Verfügbarkeit eines lauffähigen Systems; Repository-Objekte und Z-Entwicklungen werden eins zu eins übernommen.
• Nachteile: Großer Speicherbedarf durch die Duplizierung des gesamten Datenbestands; hohes Risiko der unbeabsichtigten Weitergabe sensibler Verkäuferdaten, falls Löschalgorithmen nicht lückenlos greifen.

Die selektive Migration in eine „Empty Shell“ gilt oft als der technisch überlegene Weg. Hierbei wird ein Zielsystem als leere Hülle (nur Customizing und Repository) aufgebaut, in das anschließend nur die identifizierten, relevanten Daten migriert werden.

• Vorteile: Höchste Datensicherheit, da nur autorisierte Daten das Quellsystem verlassen; das Zielsystem ist frei von historischem Ballast; ermöglicht Transformationen (z. B. Kontenplanumstellungen) während des Prozesses.
• Nachteile: Erfordert spezialisierte ETL-Tools (wie Natuvion DCS oder SAP Landscape Transformation Services) und tiefgreifendes Expertenwissen für das Mapping der Tabellenbeziehungen.

Die Herausforderung der Belegzuordnung und Anhänge

Ein zentraler Punkt im Anforderungskatalog eines Carve-Outs ist die korrekte Zuordnung von Belegen und deren Anhängen. Wenn ein Unternehmensteil veräußert wird, stellt sich die Frage: Welcher Beleg „gehört“ wem?

Im Falle eines Share Deals ist die Antwort klar: Alle historischen Belege der legalen Einheit gehen auf den Käufer über. Bei einem Asset Deal oder einem Teil-Carve-Out ist die Trennung schwieriger. Hier werden oft nur die Belege migriert, die direkt dem veräußerten Teil zuzuordnen sind. Wird nur ein Teil eines Buchungskreises ausgegliedert, so müssen z. B. alle geteilten Belege (z. B. Rechnungen, die mehrere Geschäftsbereiche betreffen) entweder dupliziert oder geschwärzt werden, was technisch extrem aufwendig ist.

Ein technisches Risiko stellt die Migration von Beleganhängen dar, die über Generic Object Services (GOS) oder externe Archivsysteme an die SAP-Belege angebunden sind. Diese Anhänge (z. B. PDF-Rechnungen, Verträge) sind für die tägliche Arbeit und spätere Prüfungen essentiell. Ohne diese Anhänge würde die NewCo zwar den Buchungssatz besitzen, aber keine Einsicht in das zugrunde liegende Originaldokument haben. Dies würde die Revisionssicherheit gefährden.

Schnittstellen und Satellitensysteme: Die Architektur der Trennung

Ein SAP-System existiert nicht im luftleeren Raum. Die Trennung und Neukonfiguration von Schnittstellen ist oft zeitaufwendiger und komplexer als die eigentliche Datenmigration. In SAP Carve-Outs müssen Verbindungen zu Drittsystemen, Cloud-Applikationen und Partnern präzise analysiert und neu aufgebaut werden.   

Bevor technische Änderungen vorgenommen werden, ist eine umfassende Integration Impact Analysis unerlässlich. Dabei müssen alle aktiven Verbindungen zu Satellitensystemen (wie Salesforce für CRM, Ariba für den Einkauf oder IBP für die Planung) sowie Middleware-Lösungen (EDI/EAI) identifiziert werden. Das Ziel ist es, nur die für die NewCo relevanten Integrationen zu migrieren und obsolete Verbindungen kontrolliert stillzulegen.   

Eine zentrale Herausforderung besteht darin, dass die Selektionslogik des Carve-Outs (z. B. basierend auf Profit Centern) konsistent über alle angebundenen Systeme hinweg angewendet werden muss. Wenn Daten in Satellitensystemen nach anderen Kriterien gefiltert werden als im SAP-Core, entstehen Inkonsistenzen. Diese können die operative Handlungsfähigkeit ab Tag 1 gefährden.   

Qualitätssicherung und Testmanagement im Carve-Out

Angesichts der enormen Risiken eines Carve-Outs – von operativen Stillständen bis hin zu rechtlichen Konsequenzen – ist ein strukturiertes Testmanagement unverzichtbar. Ein Carve-Out-Projekt erfordert dabei eine spezifische Teststrategie, die über klassische Implementierungstests hinausgeht.   

Ein effektives Testmanagement gliedert sich typischerweise in mehrere Phasen, um sowohl die technische Integrität als auch die betriebswirtschaftliche Korrektheit sicherzustellen:   

1. Technische Unit- und Integrationstests: Überprüfung des Customizings und der technischen Erreichbarkeit aller Komponenten. Hierbei werden oft grundlegende Fehler in der Systemumgebung identifiziert und behoben.
2. Funktionale Prozesstests: Validierung der End-to-End-Geschäftsprozesse (z. B. Order-to-Cash, Procure-to-Pay) unter Verwendung migrierter Daten. Ziel ist der Nachweis, dass das System am Tag 1 die gleiche Funktionalität bietet wie das Quellsystem.
3. User Acceptance Testing (UAT): Der finale Checkpoint, bei dem die zukünftigen Anwender der NewCo das System in einer realitätsnahen Umgebung abnehmen.

Ein Alleinstellungsmerkmal von Carve-Out-Tests ist das Negative Testing. Hierbei wird gezielt geprüft, ob Daten, die nicht zum Umfang der NewCo gehören, tatsächlich nicht im Zielsystem vorhanden sind. Dies ist insbesondere im Hinblick auf Compliance und den Schutz von Geschäftsgeheimnissen des Verkäufers kritisch.

Dry Runs und Cutover-Rehearsals

Vor dem eigentlichen Go-Live ist ein Dry-Run (Migrations-Generalprobe) empfehlenswert. Diese Probe simuliert den exakten Zeitplan des Cutover-Wochenendes, um die Zeitfenster für Datenentladung, Transformation, Upload und die manuellen Nacharbeiten zu validieren. Nur so lässt sich das Risiko unvorhergesehener Verzögerungen während der kritischen Downtime minimieren.

Tools zur Validierung

Um die Vollständigkeit der Migration nachzuweisen, werden automatisierte Prüfverfahren eingesetzt.

• Table Count: Vergleich der Datensätze in Quell- und Zieltabellen vor und nach der Migration.
• Fingerprint-Check: Verteilung der Datensätze auf Organisationseinheiten (Buchungskreise, Werke), um sicherzustellen, dass keine Daten „fremder“ Einheiten mitmigriert wurden.
• Fremdschlüsselprüfung: Sicherstellung, dass für alle migrierten Bewegungsdaten die entsprechenden Customizing-Einträge im Zielsystem vorhanden sind.

Compliance-Risiken und deren Minimierung

Fehler bei der Datenabgrenzung können zu ernsthaften rechtlichen Problemen führen. Wird zu wenig migriert, ist das Unternehmen nicht aussagefähig gegenüber Behörden. Wird zu viel migriert (z. B. vertrauliche Daten des Verkäufers), drohen Klagen wegen Verletzung von Geschäftsgeheimnissen oder Verstöße gegen die DSGVO. Eine saubere, tool-gestützte Dokumentation aller Migrationsschritte (Logging) ist daher die beste Versicherung gegen solche Risiken.

Zusammenfassung und Handlungsempfehlungen

Carve-Outs sind ein hochkomplexes Unterfangen, das eine enge Verzahnung von IT-Expertise, Prozessverständnis und rechtlichem Know-how erfordert. Die zentralen Erfolgsfaktoren lassen sich wie folgt zusammenfassen:

1. Frühzeitige Definition der Trennungslinie: Ob über Buchungskreise oder Profit Center – die Selektionslogik muss wasserdicht sein und von allen Stakeholdern (inkl. Wirtschaftsprüfern) abgenommen werden.
2. Wahl der richtigen Migrationsstrategie: Die selektive Migration bietet die höchste Sicherheit und Flexibilität, erfordert jedoch spezialisierte Werkzeuge und erfahrene Berater:innen.
3. Ganzheitliche Sicht auf die Systemlandschaft: Schnittstellen, Beleganhänge und Umsysteme dürfen nicht vernachlässigt werden, da sie die operative Handlungsfähigkeit ab Tag 1 bestimmen.
4. Strukturiertes Testen und Validieren: Nur durch automatisierte Vergleiche und intensive funktionale Tests kann die Datenintegrität sichergestellt werden.
5. Compliance als Leitplanke: Die Einhaltung der GoBD sichert das Unternehmen langfristig gegenüber regulatorischen Risiken ab.

Wir von der adesso business consulting verfügen über Erfahrung in der Begleitung komplexer SAP-Carve-Out-Projekte. Unser Leistungsspektrum umfasst die strategische Beratung, das technische Mapping sowie die Unterstützung in der Umsetzungs- und Go-Live-Phase. Dabei berücksichtigen wir sowohl fachliche als auch technische Aspekte, unter anderem in den Modulen FI, CO, MM und SD sowie bei der Datenmigration. Bei Vorhaben zur Systemtrennung oder Neustrukturierung von IT-Landschaften unterstützen wir mit einem strukturierten und methodischen Vorgehen. So können Risiken reduziert und eine stabile Zielarchitektur etabliert werden. Gerne stehen wir für einen unverbindlichen Austausch zur Verfügung, um individuelle Anforderungen und mögliche Vorgehensweisen zu besprechen.