Das schlechtere System hat gewonnen: Was eine 12-Wochen-M&A-Integration über ERP-Auswahl lehrt

Freitag 18:00. 80 Mitarbeiter loggen sich aus ihrem alten ERP aus. Montag 08:00. Dieselben 80 loggen sich in das neue ein.

Das neue ist objektiv schlechter.

Kontext: M&A-Integration. Ein internationaler Konzern hat 2025 einen 80-Mann-Mittelständler aus der Beratungsbranche übernommen. Vorgabe: alle Systeme und Daten in die Konzern-IT-Umgebung. Über ein Wochenende. Kein Geschäftsausfall.

Das Konzern-ERP konnte weniger als das abgelöste. Andere Kostenrechnung. Andere Reports. Zwei nicht kompatible Datenmodelle. Es musste trotzdem laufen.

In diesem Beitrag entpacke ich, wie das funktioniert hat, warum die statistischen Erwartungen das Gegenteil vorhersagten, und welche Lehren mittelständische IT-Verantwortliche aus einer M&A-Integration für die normale ERP-Auswahl mitnehmen können. Das Thema fällt direkt in meine IT-Strategie- und Projekt-Management-Beratung.

Warum die Statistik dagegen sprach

Die einschlägigen Studien zur M&A-IT-Integration sind eindeutig. Bain dokumentiert, dass 84 Prozent aller IT-Integrationen nach Akquisitionen signifikante Probleme erleben. Gartner berichtet, dass 83 Prozent aller Data-Migration-Projekte ihr Budget oder Timeline reißen. Panorama Consulting weist für 2025 bei Discrete-Manufacturing-ERP-Projekten eine Misserfolgsquote von 73 Prozent aus, mit durchschnittlichem Kosten-Overrun von 215 Prozent.

McKinsey ergänzt zur Reichweite: 30 bis 50 Prozent des Deal-Values gehen durch langsame oder fehlerhafte IT-Integration verloren. Weniger als 20 Prozent der Acquirer verbessern ihre IT-Kosten und -Qualität nach einem Merger. Bei vier von fünf Deals materialisiert sich der versprochene Konsolidierungs-Effekt gar nicht.

Vor diesem Hintergrund war ein Cut-Over zum Festpreis in einem Wochenende für einen 80-Mann-Mittelständler eine sportliche Vorgabe. Die übliche Mindestdauer für Mid-Market-IT-Integrationen liegt nach Bain bei 12 bis 18 Monaten.

Wir hatten 12 Wochen.

Die Ausgangslage

Der Mittelständler war über 14 Jahre organisch gewachsen. Sein ERP-Setup war an die spezifischen Workflows der Beratungsbranche gut angepasst, dokumentation der Erweiterungen lag aber nur partiell vor. Zwei unterschiedliche Kostenrechnungs-Modelle existierten, weil eine frühere Tochtergesellschaft ihre eigene Logik mitgebracht hatte. Berichtswege, Approval-Strukturen und Provisionierungs-Regeln waren über die Jahre tief in das System gewachsen.

Das Konzern-ERP war auf eine andere Branche, eine andere Größenordnung und eine andere Reporting-Philosophie ausgelegt. Es konnte vieles, was der Mittelständler nicht brauchte. Und es konnte weniger von dem, was der Mittelständler täglich nutzte. Die Vorgabe war nicht „bestes System auswählen". Die Vorgabe war „Konzern-System gewinnt, Daten müssen rein".

Diese Konstellation ist nach McKinsey und Bain der Normalfall bei M&A-Integrationen. Das Akquisitionssystem setzt sich durch, nicht das technisch bessere. Was über Erfolg oder Misserfolg entscheidet, ist die Disziplin im Vorgehen.

Das Vorgehen: 12 Wochen plus ein Wochenende

Wochen 1 bis 4: Discovery

Reverse-Engineering der Legacy-Systeme. Jede Schnittstelle, jeder Custom-Field, jede manuell gepflegte Übersetzungs-Tabelle wurde dokumentiert. Das war der zeitaufwendigste Block. Was bei einer dokumentierten Software-Architektur in zwei Wochen erledigt wäre, dauerte beim gewachsenen Mittelstands-Setup vier.

Die Discovery-Phase ist nach McKinsey-Daten der Schritt, den am meisten Projekte unterschätzen. Das Risiko: man beginnt das Mapping, ohne zu wissen, was am unteren Ende der Quellsysteme wirklich passiert. Genau das verursacht die 215 Prozent Cost-Overrun, die Panorama für 2025 misst.

Wochen 5 bis 10: Mapping und Testing

Detailliertes Datenmapping pro Quell-Ziel-Feld. Mehrere Testläufe in einer Stage-Umgebung. Bei jedem Testlauf wurde gemessen, wie weit die Datenintegrität war, wo Mapping-Lücken aufkamen und welche Edge-Cases bei der Konvertierung der zwei Kostenrechnungs-Modelle Probleme machten.

Drei vollständige Probeläufe vor dem echten Cut-Over. Jeder Probelauf brachte neue Findings, die Mapping-Korrekturen verursachten. Beim dritten Probelauf war die Datenintegrität auf einem Niveau, bei dem der echte Cut-Over möglich war.

Wochen 11 bis 12: Go-Live-Prep

Runbooks für jeden Schritt. Wer drückt um wieviel Uhr welchen Button. Welche Validierung läuft danach. Wer wird informiert. Was ist der Rollback-Pfad, falls eine Validierung fehlschlägt. Trainings für das Cut-Over-Team. Kommunikations-Plan für die 80 Mitarbeiter, die am Montagmorgen mit dem neuen System arbeiten.

Wichtiger Punkt: der Rollback-Pfad wurde geplant, obwohl wir wussten, dass wir ihn am Wochenende kaum würden ziehen können. Allein das Wissen, dass es ihn gibt, machte die operativen Entscheidungen am Cut-Over-Wochenende leichter.

Das Cut-Over-Wochenende

Freitag 18:00. Letzte produktive Buchung im alten System. Logout aller Nutzer. Beginn des automatisierten Daten-Exports.

Samstag und Sonntag liefen die Konvertierungs- und Validierungs-Skripte. Stunde für Stunde wurde gegen die im Vorlauf definierten Acceptance-Kriterien geprüft. Bei jedem Validierungsschritt waren mindestens zwei Personen aus dem Projekt anwesend.

Montag 08:00. Logins frei. Erste produktive Buchung im neuen System um 08:14.

Die Ergebnisse

Datenintegrität zwischen Quell- und Zielsystem: 99,3 Prozent. Die fehlenden 0,7 Prozent waren bewusst aus dem Scope genommen worden, weil sie historische Datensätze betrafen, die im Konzern nicht weiter relevant waren.

Finance-Abstimmung von 3 Tagen auf 6 Stunden reduziert. 95 Prozent der Abstimmungs-Schritte waren nach dem Cut-Over automatisiert. Vor dem Projekt hatte die Buchhaltung des Mittelständlers drei Werktage gebraucht, um den Monatsabschluss gegen die Vorsysteme zu prüfen. Nach dem Cut-Over waren es sechs Stunden, weil das Mapping in der Discovery-Phase die Voraussetzungen geschaffen hatte.

Keine kritischen Fehler. Kein Rollback. Keine Nacharbeit über das geplante Fine-Tuning hinaus. Festpreis exakt eingehalten.

Der Integration-Lead vom Käufer-Konzern schrieb nach Go-Live (anonymisiert):

„Bei anderen Firmenzusammenschlüssen waren die Go-Lives chaotisch. Mit Renés Planung lief alles wie am Schnürchen. Wir wussten genau, was passiert, wann es passiert und was schiefgehen könnte. Es ist nichts schiefgegangen."

ERP-Einführung versus M&A-Cut-Over: warum sich das Vorgehen unterscheidet

Klassische ERP-Auswahl und M&A-IT-Integration werden im Mittelstand oft mit demselben Projekt-Reflex angegangen. Das ist ein häufiger Fehler. Die beiden Disziplinen haben unterschiedliche Erfolgskriterien.

Was Mittelständler aus dem Fall für die normale ERP-Auswahl mitnehmen

Auch ohne M&A-Druck ist die Lehre übertragbar. Vier Punkte, die aus diesem Projekt in jede Beratung einfließen, die ich seitdem mache.

Lehre 1: Vorgehen schlägt System

Das Konzern-ERP war objektiv das schwächere Werkzeug. Trotzdem lief der Cut-Over besser als die meisten klassischen ERP-Einführungen, die mit dem theoretisch perfekten System starten und im Adoptions-Sumpf versinken. Was den Unterschied macht, ist die Projekt-Disziplin: Discovery vor Mapping, Mapping vor Testing, Testing vor Go-Live. Nicht die Feature-Liste.

Für Mittelständler ohne M&A-Druck bedeutet das: Die Frage „Welches System hat die meisten Funktionen?" ist im Auswahlprozess nicht die wichtigste. Die wichtigere Frage ist „Welches Vorgehen passt zu unserer Disziplin?". Ein einfacheres System mit sauberem Projekt-Vorgehen schlägt ein komplexes System mit improvisierter Einführung.

Lehre 2: Discovery braucht 30 Prozent der Projektzeit, nicht 5 Prozent

In unserem Fall waren das vier von zwölf Wochen, also genau 33 Prozent. Bei klassischen ERP-Einführungen im Mittelstand sehe ich oft, dass Discovery in zwei Workshops abgehandelt wird und die restliche Zeit für Konfiguration und Customizing verwendet wird. Das ist die Quelle der 215-Prozent-Cost-Overruns, die Panorama für 2025 misst.

Konkret: Wer eine ERP-Einführung in 12 Monaten plant, sollte 3 bis 4 Monate für Discovery einplanen. Reverse-Engineering der aktuellen Systeme, Dokumentation aller informellen Workflows, Aufdeckung der Schatten-IT in Excel-Dateien. Das spart in Monat 7 bis 10 die fast immer eintretenden Verzögerungen.

Lehre 3: Testläufe sind keine Option

Drei vollständige Testläufe in unserem Projekt. Jeder hat Findings produziert, die das nächste Mapping korrigieren mussten. Ohne diese Testläufe wäre der echte Cut-Over zu einem Improvisations-Wochenende geworden, mit unkalkulierbarem Schadenspotenzial.

Für klassische ERP-Einführungen gilt dieselbe Disziplin. Mindestens ein vollständiger End-to-End-Test mit echten Quelldaten in einer produktionsnahen Stage-Umgebung. Idealerweise zwei. Wer das überspringt, weil „wir schon UAT machen", verwechselt Akzeptanz-Test mit System-Test. Beides ist nötig.

Lehre 4: Runbook schlägt Improvisation

Das Cut-Over-Wochenende lief deshalb ruhig, weil jeder Schritt vorab definiert war. Wer welche Aktion um welche Uhrzeit, mit welcher Validierung danach, mit welchem Eskalationspfad. Improvisation kam nicht vor.

Für klassische ERP-Einführungen ist das Runbook-Prinzip oft unterentwickelt. Go-Live wird als „Projektabschluss" gefeiert, ohne dass es einen schriftlich fixierten Stundenplan gibt, was Stunde für Stunde passiert. Konsequenz: niemand weiß, ob die Cash-Abstimmung am Mittwoch um 10:00 oder erst Freitag um 16:00 läuft. Das produziert die Reibung, die in 73 Prozent der Discrete-Manufacturing-Projekte zu Problemen führt.

Was der Fall NICHT bedeutet

Vier Klarstellungen, weil die Story zu einfacheren Schlüssen einlädt, als sie tragfähig sind.

Erstens: Es bedeutet nicht, dass Funktionsumfang irrelevant ist. Für eine reguläre ERP-Auswahl ohne M&A-Druck ist die Passung der Kernfunktionen zur Geschäftslogik weiterhin entscheidend. Was die M&A-Geschichte zeigt, ist die Sekundärrolle von Funktionsumfang gegenüber Vorgehensdisziplin, nicht seine Bedeutungslosigkeit.

Zweitens: Es bedeutet nicht, dass jedes ERP migrationsfähig in zwölf Wochen ist. Unser Fall hatte 80 Mitarbeiter, eine überschaubare Datenmenge und einen klar definierten Scope. Größere Setups mit mehreren Tochtergesellschaften, internationaler Komplexität und regulatorischen Datenbeschränkungen brauchen die Bain-Standard-Timeline von 12 bis 18 Monaten oder länger.

Drittens: Es bedeutet nicht, dass schlechtere Systeme bevorzugt werden sollten. Wenn die Wahl frei ist, also außerhalb von M&A-Kontexten, gilt: das passendere System gewinnt. M&A-Integrationen sind ein Spezialfall, in dem die Wahl nicht frei ist.

Viertens: Es bedeutet nicht, dass das gleiche Vorgehen ohne erfahrene Begleitung funktioniert. Die 12 Wochen plus ein Wochenende waren möglich, weil das Projekt-Team die Discovery-Aufgaben in vier Wochen vollständig bewältigt hat. Wer diese Erfahrung nicht hat, wird die Vorlaufphase deutlich länger ansetzen müssen.

Häufige Fragen zur M&A-IT-Integration

Wie unterscheidet sich M&A-IT-Integration von einer normalen ERP-Einführung?

Bei einer normalen ERP-Einführung ist die System-Auswahl der zentrale Hebel. Bei einer M&A-Integration ist sie vorgegeben. Der Hebel verschiebt sich zum Daten-Mapping, zur Cut-Over-Choreographie und zur Disziplin im Discovery. Erfolg wird nicht an Adoption über Monate gemessen, sondern an Datenintegrität am Stichtag.

Wie lange dauert ein M&A-IT-Integrationsprojekt?

Für Mid-Market-Deals mit klar definierten Carve-Out-Strukturen sind 8 bis 16 Wochen plus Cut-Over-Wochenende realistisch, sofern Erfahrung im Team vorhanden ist. Bain dokumentiert für komplexere Deals 12 bis 18 Monate als Standard. Cross-border-Deals und Mehrgesellschaftsstrukturen liegen häufig bei 2 bis 3 Jahren.

Was kostet ein M&A-ERP-Cut-Over zum Festpreis?

Festpreise sind im Mittelstand bei klar abgrenzbarem Scope möglich. Voraussetzung: eine belastbare Discovery-Phase mit dokumentiertem Scope und einer definierten Acceptance-Liste. Ohne diese Vorab-Klarheit ist Time-and-Material-Abrechnung die ehrlichere Option. Bei unserem Fall war der Festpreis möglich, weil der Carve-Out-Umfang vom Käufer-Konzern klar definiert war.

Wer haftet bei einem fehlgeschlagenen Cut-Over?

Vertraglich der Implementierungs-Partner für das, was im Scope war. Faktisch das Käufer-Management, weil die operativen Folgen eines fehlgeschlagenen Cut-Overs alle Geschäftsprozesse treffen. Aus diesem Grund ist die Rolle des dedizierten Integration-Leads beim Käufer nach McKinsey-Daten der wichtigste Erfolgsfaktor. 75 Prozent Erfolgsrate mit benanntem Lead, 25 Prozent ohne.

Was passiert mit den Legacy-Systemen nach dem Cut-Over?

In unserem Fall blieben die alten Systeme drei Monate im Read-Only-Modus für Audit- und Recherche-Zwecke verfügbar, dann wurden sie archiviert. Die Frist hängt von den regulatorischen Anforderungen ab. Für deutsche GmbH-Strukturen sind 10 Jahre Aufbewahrung typisch, was nicht bedeutet, dass die Live-Systeme so lange laufen müssen. Eine Archiv-Snapshot-Lösung reicht in der Regel.

Wann ist der richtige Zeitpunkt, mit der Cut-Over-Planung zu starten?

Nach McKinsey: während der Due Diligence, nicht nach dem Closing. Wer die IT-Integrationsplanung erst nach Closing startet, hat die ersten 100 Tage bereits verloren. In unserem Fall begann die Discovery am Tag nach dem Signing, vor dem operativen Closing.

Wie gehe ich vor, wenn das Käufer-System Funktionen vermissen lässt, die wir brauchen?

Drei Optionen, in dieser Reihenfolge zu prüfen. Erstens: Workaround im Käufer-System (oft günstiger als gedacht, wenn der Workflow neu gedacht wird). Zweitens: bilaterales Custom-Field mit klarer Owner-Verantwortung. Drittens: separates Tool als Satellit. Workaround-Suche ist der seltene Fall, in dem weniger Funktionsumfang besser ist, wenn er den Daten-Cut-Over vereinfacht.

Nächster Schritt

Steht Ihnen eine M&A-IT-Integration bevor oder kommt eine größere ERP-Migration auf Sie zu? Ich begleite mittelständische IT-Verantwortliche bei Discovery-Phase, Daten-Mapping, Runbook-Erstellung und Cut-Over-Choreographie, mit nachweisbarer Erfolgsbilanz auch in herausfordernden Zeitfenstern.

→ Kostenloses Erstgespräch buchen

→ Oder vorher weiterlesen: IT-Strategie und Systemauswahl · Datenqualität im Mittelstand · Cash Management: ERP-Anforderungen überambitioniert · ERP-Anbietermarkt 2026: 131 Kriterien

Quellen und weiterführende Studien: Bain: M&A IT Integration Services · McKinsey: Understanding the Strategic Value of IT in M&A · Panorama Consulting: 2025 ERP Report · Godlan: ERP Implementation Failure Statistics 2025 · PMI Stack: 50+ Post-Merger Integration Statistics 2026 · Deloitte 2025 M&A Trends Survey