Post-Merger-IT — die Integration wird in der Inventurphase entschieden, nicht im Zielbild

Nach dem Zukauf zählt jeder Monat doppelt — Übergangsvereinbarungen laufen ab, Synergiezusagen stehen im Vorstandsprotokoll, und zwei gewachsene Landschaften kennen einander nicht. Warum die ersten 100 Tage der IT-Integration eine Inventarfrage sind, welche drei Zahlen der Integrationsleiter sofort braucht und wieso die schöne Zielarchitektur warten kann.

Am Tag nach dem Closing hat die IT-Integration ein Publikum, das sie nie wieder loswird: den Vorstand, der Synergien zugesagt hat, den Verkäufer, dessen Übergangsleistungen mit Fristablauf teurer werden, und zwei Belegschaften, die wissen wollen, welches der beiden Systeme überlebt. In dieser Lage wird gern zuerst am Zielbild gearbeitet — es ist die angenehmste Aufgabe, sie fühlt sich strategisch an, und sie ist verschiebbar. Die unangenehme, nicht verschiebbare Aufgabe heißt anders: Wissen, was da ist. Auf beiden Seiten. Vollständig.

Die Due Diligence hat das nicht erledigt

Die verbreitete Annahme, die Prüfphase vor dem Kauf habe die IT ja durchleuchtet, hält der Realität selten stand. Due Diligence arbeitet unter Zeitdruck, mit beschränktem Zugang und auf Managementflughöhe: Großsysteme, Großverträge, offensichtliche Risiken. Die gewachsene Fläche — die dreihundert kleineren Anwendungen, die Fachbereichslösungen, die Schatten-IT des Zukaufs — sieht sie strukturell nicht. Genau in dieser Fläche stecken aber die Kosten der Integration: jede unbekannte Anwendung ist ein unbekannter Migrationsposten, ein unbekannter Vertrag, ein unbekanntes Sicherheitsrisiko unter neuer Verantwortung.

Drei Zahlen vor jeder Strategie

Was die Integrationsleitung in den ersten 100 Tagen wirklich braucht, sind keine Architekturdiagramme, sondern drei Auswertungen:

• Die Terminleiste. TSA-Fristen, Vertragslaufzeiten und stille Verlängerungen beider Seiten, sortiert nach Datum. Sie diktiert die Reihenfolge — nicht die Architektur. Ein System unter auslaufender TSA schlägt jedes strategisch wichtigere Projekt, weil sein Termin nicht verhandelbar ist.
• Die Doppelliste. Beide Landschaften auf eine Fähigkeitsstruktur gelegt: Wo betreiben beide Häuser Systeme für dasselbe Können? Das ist die Synergieliste, aus der die Zusagen des Deals tatsächlich bezahlt werden — und sie entsteht nur, wenn beide Bestände auf derselben Capability-Map stehen statt in zwei Ordnungssystemen nebeneinander.
• Das Abhängigkeitsbild der Kandidaten. Für jedes Konsolidierungsopfer die Frage: Was hängt daran — Schnittstellen, Prozesse, Verträge? Die teuersten Integrationsunfälle sind abgeschaltete Systeme, von denen noch etwas abhing, das niemand kannte.

Alle drei sind Auswertungen eines Inventars. Existiert es, sind sie in Tagen verfügbar. Existiert es nicht, beginnt die Integration mit einer mehrmonatigen Erhebung — unter genau dem Zeitdruck, den die TSA-Uhr erzeugt.

Die Integration als Pflege-Bewährungsprobe

Die Inventur des Zukaufs hat eine Eigenschaft, die sie von der normalen Bestandsaufnahme unterscheidet: Die Wissensträger sind flüchtig. Schlüsselleute des gekauften Hauses gehen in den ersten Monaten — und mit ihnen das undokumentierte Wissen über Systeme, Abhängigkeiten und Altlasten. Jede Woche früher, in der dieses Wissen als bestätigte Angabe im Bestand landet, ist unwiederbringlich wertvoll. Der Mechanismus dafür ist derselbe Bestätigungskreislauf, der den Bestand auch im Normalbetrieb trägt: kleine, konkrete Fragen an die, die es wissen — nur eben mit erhöhter Dringlichkeit.

Und noch etwas spricht dafür, die Integration auf einem gepflegten Bestand zu fahren statt auf Projekt-Excel: Die Integration endet, die Regulierung nicht. Das zusammengeführte Haus schuldet ab Tag eins Meldefähigkeit, Dokumentation und im Zweifel ein DORA-Register über beide Altlandschaften. Ein Integrationsprojekt, das nebenbei den dauerhaft gepflegten Gesamtbestand erzeugt, zahlt doppelt aus. Eines, das mit Wegwerf-Tabellen arbeitet, hinterlässt nach dem Abschlussbericht dieselbe Unwissenheit — nur größer.