Wie Sie bei übernahmen systemlandschaften in 90 tagen sicher zusammenführen

Übernahmen sind Hochrisiko-Projekte – nicht nur finanziell oder organisatorisch, sondern besonders in der IT. In vielen Fällen entscheidet die Geschwindigkeit und Sicherheit der Zusammenführung von Systemlandschaften darüber, ob der erwartete Mehrwert schnell realisiert wird oder sich in technischen Schulden und langen Stabilitätsproblemen verliert. Ich habe in den letzten zwölf Jahren zahlreiche Integrationen begleitet; aus dieser Praxis heraus habe ich einen pragmatischen 90‑Tage‑Fahrplan entwickelt, der auf Geschwindigkeit, Risikominimierung und klaren Verantwortlichkeiten basiert. In diesem Artikel teile ich ihn mit Ihnen – konkret, umsetzbar und mit Hinweisen auf Tools und typische Stolperfallen.

Mein Ziel für 90 Tage

Die Kernfrage, die ich zu Beginn stelle, lautet: Welche Mindestfunktionalität muss in 90 Tagen stabil zusammenarbeiten, damit das Business den erwarteten Wert zieht? Nicht alles muss in dieser Zeit konsolidiert werden; wichtig ist, priorisiert und iterativ vorzugehen. Mein Ziel ist immer ein stabiles, getestetes Baselinestate, das Produktionsprozesse ohne Brüche unterstützt und gleichzeitig technische Schuld durch temporäre Workarounds kontrolliert.

Tag 0–7: Rapid Assessment und Governance

In der ersten Woche geht es um schnelle, faktenbasierte Entscheidungen.

• Schnellaufnahme der Landschaften: Ich erstelle ein Dashboard mit kritischen Systemen (ERP, CRM, Zahlungsabwicklung, Identity & Access Management, Integrationsplattform) und markiere „Must‑Keep“, „Can‑Replace“, „Bridge/Temporary“.
• Risikokategorien definieren: Datenqualität, Downtime‑Risiko, Compliance, Schnittstellen mit externen Partnern.
• Governance aufsetzen: Ein kleines Steering‑Team mit Business‑Ownern, IT‑Architect, Security und einem Integrations‑Lead (meist ich oder ein dedizierter Architekt). Klare Entscheidungsbefugnisse für Schnittstellenänderungen.
• Kommunikationsplan: Tägliche 15‑min Standups, 3‑mal wöchentliches Steering‑Update, Stakeholder‑Newsletter.

Tag 8–21: Stabilitäts‑und Integrationsplan (Minimal Viable Integration)

Jetzt definiere ich die minimale, aber komplette Kette von End‑to‑End‑Prozessen, die in 90 Tagen funktionieren muss (z. B. Bestellung bis Lieferung, Fakturierung, Stammdaten‑Synch). Für jeden Prozess notiere ich:

• Welche Systeme involviert sind
• Welche Schnittstellen existieren
• Welcher Integrationsmodus nötig ist (synchron vs. asynchron)
• Welche Datenobjekte kritisch sind und Qualitätstoleranzen

Ich priorisiere oft nach dem Prinzip: Impact x Probability. Prozesse mit hohem Business‑Impact und hoher Störanfälligkeit bekommen Vorrang.

Tag 22–45: Schnellbrücken (Bridges) bauen und testen

In dieser Phase implementiere ich sichere, reversierbare Brücken zwischen Systemen statt sofortiger Migrationen. Gründe:

• Minimiert Risiko gegenüber Big‑Bang‑Cutovers
• Ermöglicht schrittweise Datenqualitätsaufbereitung
• Erlaubt parallele Betriebsszenarien

Technische Umsetzung:

• Nutzen Sie bewährte Integrationsplattformen wie Mulesoft, Dell Boomi oder Microsoft Azure Integration Services für schnelle Orchestrierung.
• Setzen Sie API‑Gateway (z. B. Kong, Apigee) ein, um Schnittstellen zu virtualisieren und Versionierung sicherzustellen.
• Implementieren Sie idempotente Consumer/Producer‑Patterns, um Doppelverarbeitung bei Retry zu verhindern.

Ich empfehle, jeden Bridge‑Use‑Case automatisiert zu testen (Contract Tests + End‑to‑End Smoke Tests) bevor ein Produktiv‑Cut erfolgt.

Tag 46–60: Datenpflege, Mapping und Governance

Daten sind der kritische Engpass. In dieser Phase arbeite ich eng mit Fachbereichen an folgenden Aufgaben:

• Datenprofiling: Erkennen von Duplikaten, fehlenden Feldern und Formatabweichungen.
• Datamapping und Transformationsregeln: Dokumentiert in einem zentralen Repository (z. B. Confluence + Export als CSV/Excel für ETL‑Tools).
• Datenqualitäts‑SLAs: Wer liefert welche Qualität, wie wird Nacharbeit eskaliert?

Tools wie Talend, Informatica oder Azure Data Factory helfen bei automatisierten Transformationspipelines. Ich achte darauf, dass Transformationslogik versioniert und nicht in ad‑hoc Skripten verstreut ist.

Tag 61–75: Cutover‑Tests und Go/No‑Go Kriterien

Jetzt werden die Übergänge simuliert und die Produktionsbereitschaft geprüft:

• Simulierte Lasttests für kritische Prozesse (Peak‑Szenarien)
• End‑to‑End Testläufe inklusive Fachbereichs‑Abnahmen
• Rollback‑Pläne schriftlich und geübt (Backout‑Checkliste, Time‑To‑Restore)
• Sicherheits‑ und Compliance‑Checks abgeschlossen

Meine Go/No‑Go Kriterien sind praktisch: keine kritischen P1‑Bugs, Datenintegrität innerhalb tolerierbarer Grenzen, Monitoring/Alerting steht und ein Support‑Rota ist organisiert.

Tag 76–90: Prod‑Cut und Stabilisierung

Der eigentliche Cut wird in einem engen Zeitfenster durchgeführt, häufig in mehreren Wellen:

• Wave 1: Niedrigrisiko‑Transaktionen
• Wave 2: Kernprozesse
• Wave 3: Randprozesse

Ich stelle sicher, dass während der ersten 72 Stunden ein Incident‑War‑Room aktiv ist (physisch oder virtuell) mit allen relevanten SMEs. Monitoring ist in dieser Phase entscheidend: Service‑Level‑Dashboards, Alerts für Anomalien in Volumen oder Latenz, sowie Health‑Checks auf Integrationslayern.

Praktische Checkliste (als Tabelle)

Häufige Fehler, die ich vermeide

• Zu viel auf einmal wollen: Big‑Bang als Risikoquelle. Lieber schrittweise und kontrolliert integrieren.
• Kein klares Owner‑Modell: Ohne Verantwortliche entstehen Latenzen bei Entscheidungen.
• Datenqualitätsprobleme unterschätzen: Sie sind Zeitfresser und können Betriebsprozesse massiv stören.
• Tests vernachlässigen: Contract‑ und End‑to‑End‑Tests sind nicht optional.

Wenn Sie möchten, kann ich Ihren spezifischen Use‑Case in einem Review durchgehen oder Ihnen eine angepasste 90‑Tage‑Roadmap mit konkreten Deliverables erstellen. Teilen Sie mir Ihre kritischen Systeme und ein angestrebtes Go‑Live‑Datum mit – dann erarbeiten wir gemeinsam den minimalen, sicheren Pfad bis zur Produktion.