SAP-Systeme nach M&A zusammenführen: vom Ist-Bild zum Template

Nach einem Merger oder einer Übernahme stehen plötzlich zwei oder mehr SAP-Systeme nebeneinander — und ein Synergieversprechen, das auf deren Zusammenführung baut. Die klassische Antwort darauf: Workshops mit den Key-Usern beider Seiten, monatelange Aufnahme, und am Ende entscheidet oft nicht die Faktenlage, sondern wer lauter argumentiert.

Das Grundproblem: Fremde Systeme lassen sich kaum vergleichen. Jedes bringt seine eigene, meist veraltete Dokumentation mit — in unterschiedlicher Tiefe, Struktur und Begrifflichkeit. Und mindestens eines der Systeme hat niemand im eigenen Team aufgebaut.

Es geht strukturierter. Vier Schritte, vom Ist-Bild zum ausgerollten Template.

Schritt 1: Feature Map je System aufbauen

Bevor irgendetwas verglichen wird, braucht jedes System dasselbe Raster: eine Feature Map — Business Areas, Capabilities und Features, jeweils mit der Unterscheidung Standard oder Eigenentwicklung und mit der realen Nutzung dahinter.

Der entscheidende Punkt ist nicht die Landkarte an sich, sondern dass beide Systeme mit demselben Maßstab vermessen werden. Erst wenn „Fakturierung” in System A dasselbe bedeutet wie in System B, wird aus zwei Inventaren eine Vergleichsgrundlage.

Schritt 2: Prozesse identifizieren

Die Feature Map zeigt, was implementiert ist. Die zweite Ebene zeigt, wie damit gearbeitet wird: die realen End-to-End-Prozesse, rekonstruiert aus den Belegflüssen jedes Systems — mit allen Varianten und ihren Häufigkeiten.

Gerade im M&A-Kontext ist das der Schritt, der Überraschungen liefert. Zwei Unternehmen können dieselben Module einsetzen und trotzdem völlig unterschiedlich arbeiten: hier hochautomatisiert, dort mit manuellen Sonderwegen, die im Handbuch nirgends stehen.

Schritt 3: Template festlegen

Jetzt liegen beide Systeme in derselben Struktur nebeneinander — und die Template-Entscheidung wird von der Machtfrage zur Sachfrage. Pro Capability lässt sich beantworten:

1. Welche Seite ist näher am Standard? Weniger Abstand heißt weniger Migrationsaufwand und weniger Pflege im Zielbild.
2. Wo liegt das Volumen? Ein Prozess, der 90 % der Belege trägt, hat mehr Gewicht als eine selten genutzte Variante — egal, von welcher Seite sie kommt.
3. Welche Eigenentwicklungen hängen daran? Jede übernommene Abweichung will im Template weiterbetrieben werden. Ungenutzte Individualisierung ist der einfachste Synergiegewinn: Sie wird nicht migriert, sondern verabschiedet.

Das beste Template ist nicht das System des größeren Partners. Es ist die Kombination der Prozesse, die nachweislich funktionieren — pro Capability entschieden, nicht pauschal.

Schritt 4: Template ausrollen

Der Rollout wird planbar, weil die Lücken pro Standort vorher sichtbar sind: Wo arbeitet eine Einheit bereits nah am Template, wo weicht sie stark ab, wo hängen lokale Eigenentwicklungen an Prozessen, die es im Zielbild nicht mehr gibt? Aus der Gegenüberstellung wird eine Rollout-Reihenfolge mit begründeten Aufwänden — statt einer Wette.

Und nach jedem Rollout-Schritt lässt sich gegen die Realität messen: Die Belegdaten zeigen, ob die Einheit tatsächlich im Template arbeitet oder alte Wege weiterlebt.

Warum Fakten hier doppelt zählen

M&A-Projekte stehen unter Zeitdruck und sind politisch aufgeladen. Die Frage „welches System führt?” ist immer auch eine Statusfrage — und genau deshalb braucht sie eine Antwort, die nicht verhandelbar ist. Eine gemeinsame, datenbasierte Sicht auf beide Systeme nimmt der Debatte die Schärfe: Man streitet nicht mehr über Erinnerungen, sondern entscheidet über Zahlen.

---

Genau dafür ist Conjola gebaut: Jedes geerbte System wird als eigene Landscape im selben Mandanten angelegt und einzeln aus seinen echten Belegdaten redokumentiert — Prozesse, Features und Custom Code im selben Raster. Die Systeme lassen sich nebeneinanderstellen; Überschneidungen und Abweichungen werden sichtbar. Die Template-Entscheidung treffen Sie — aber auf Fakten.