Nach einer Akquisition wird in IT-Organisationen sehr schnell über Systeme gesprochen. Zu schnell.
Die eigentliche Arbeit der ersten 100 Tage ist keine technische. Sie ist eine Führungsarbeit. Wer das nicht versteht, setzt Zielarchitekturen auf, die an der Realität der übernommenen Organisation vorbeigeplant sind — und wundert sich, warum Integration langsamer vorangeht als geplant, warum lokale Teams nicht mitziehen, warum Risiken auftauchen, die im Datenraum nicht sichtbar waren.
Ich habe Post-Merger-Integration nicht als theoretisches Konzept erlebt, sondern als reale Führungsaufgabe: mit Zeitdruck, unterschiedlichen Erwartungshaltungen, historisch gewachsenen Strukturen und Menschen, die zu Recht fragen, was diese Veränderung für ihre Arbeit bedeutet.
Das ist verständlich. IT ist in solchen Situationen sichtbar. Wenn etwas nicht funktioniert, merkt es jeder sofort. Wenn Zugriffe fehlen, Prozesse haken oder Entscheidungen ausbleiben, entsteht Unruhe. Gerade deshalb ist die Versuchung groß, die ersten 100 Tage nach einer Akquisition vor allem technisch zu denken.
Aus meiner Sicht ist genau das der erste Fehler.
Die ersten 100 Tage sind nicht in erster Linie eine technische Phase. Sie sind eine Führungsphase. Eine Orientierungsphase. Eine Phase, in der Vertrauen entsteht oder verloren geht. Technologie spielt dabei eine große Rolle, aber sie ist nicht der Ausgangspunkt. Der Ausgangspunkt ist die Frage, wie zwei Organisationen anfangen, gemeinsam steuerbar zu werden, ohne vorschnell die eine Logik über die andere zu stülpen.
Ich habe Post-Merger-Integration aus IT-Sicht nicht als theoretisches Konzept erlebt, sondern als reale Führungsaufgabe. Mit Zeitdruck, unterschiedlichen Erwartungshaltungen, historisch gewachsenen Strukturen, berechtigten Sicherheitsanforderungen und Menschen, die sich fragen, was diese Veränderung konkret für ihre Arbeit bedeutet.
Was dabei zählt, ist weniger die perfekte Zielarchitektur am Tag 30. Entscheidend ist, ob die Organisation in den ersten 100 Tagen Klarheit, Stabilität und Vertrauen schafft. Und am Ende dieser Phase muss mehr vorliegen als ein gutes Gefühl: ein konkreter Projektplan mit Aufgaben, Prioritäten, Verantwortlichkeiten, Abhängigkeiten und realistischen nächsten Schritten.
Integration beginnt nicht mit Migration, sondern mit Verständnis
Viele Integrationsprogramme starten mit einer naheliegenden Frage: Was muss wohin migriert werden?
Welche Systeme bleiben? Welche werden abgelöst? Welche Plattform setzt sich durch? Wie schnell können Benutzer, Daten, Prozesse und Standorte integriert werden?
Diese Fragen sind wichtig. Aber sie kommen zu früh, wenn das Verständnis für den Kontext fehlt.
Vor jeder technischen Entscheidung steht eine andere Arbeit: verstehen, was vorhanden ist. Nicht nur auf Architekturdiagrammen, sondern in der operativen Realität. Welche Systeme sind kritisch? Welche Prozesse hängen an scheinbar kleinen Anwendungen? Wo gibt es lokale Besonderheiten, die nie sauber dokumentiert wurden, aber jeden Tag das Geschäft am Laufen halten? Welche Abhängigkeiten kennen nur einzelne Personen?
Gerade im Mittelstand sind IT-Landschaften selten idealtypisch. Sie sind gewachsen. Oft pragmatisch, manchmal unsauber, aber häufig erstaunlich wirksam. Wer das vorschnell als Legacy abwertet, übersieht den eigentlichen Punkt: Diese Strukturen haben eine Organisation über Jahre getragen.
Das heißt nicht, dass man sie konservieren sollte. Aber man sollte sie verstehen, bevor man sie verändert.
In den ersten 100 Tagen geht es daher nicht darum, möglichst viele Systeme auf eine Zielplattform zu schieben. Es geht darum, eine belastbare Sicht auf Risiken, Abhängigkeiten und Entscheidungsbedarfe zu bekommen. Eine gute Integrationsentscheidung braucht Substanz. Und Substanz entsteht nicht durch Annahmen, sondern durch saubere Analyse und ehrliche Gespräche.
Gute Sparringspartner entscheiden über die Qualität der Integration
In Post-Merger-Situationen wird oft über Governance gesprochen. Meist meint man damit Gremien, Freigaben, RACI-Matrizen und Reportingformate.
Dabei gibt es nicht nur den IT-Workstream. Akquisitionen betreffen nahezu alle Bereiche: Finance, HR, Legal, Operations, Sales, Einkauf, Compliance, Kommunikation und häufig auch Produkt- oder Entwicklungsbereiche. Jeder dieser Workstreams hat eigene Risiken, eigene Abhängigkeiten und eigene Zeitlinien. Gerade deshalb ist die Qualität der Zusammenarbeit zwischen den verantwortlichen Personen so wichtig.
Das ist nicht falsch. Aber aus meiner Sicht wird ein anderer Punkt unterschätzt: die Qualität der Zusammenarbeit zwischen den verantwortlichen Personen auf beiden Seiten.
Eine Akquisition bringt immer ein Machtgefälle mit sich. Eine Seite kauft, die andere wird integriert. Diese Realität kann man nicht wegmoderieren. Aber man kann entscheiden, wie professionell man damit umgeht.
Für die IT ist ein belastbarer Sparringspartner auf der anderen Seite enorm wichtig. Das gilt aber nicht nur für IT. Jeder Workstream braucht Menschen, die nicht nur Anforderungen weitergeben, sondern den Kontext verstehen. Menschen, die zuhören, kritisch hinterfragen und trotzdem lösungsorientiert bleiben. Menschen, mit denen man offen über Risiken, Zwänge und sinnvolle Reihenfolgen sprechen kann.
Das klingt trivial. Ist es aber nicht.
Ohne dieses Vertrauen wird Integration schnell mechanisch. Dann entstehen Listen, Deadlines und Eskalationen, aber kein echtes gemeinsames Bild. Mit gutem Sparring entsteht dagegen etwas anderes: realistische Priorisierung. Man kann unterscheiden zwischen dem, was aus Konzernsicht zwingend ist, dem, was aus Security-, Compliance-, Finance- oder HR-Sicht nicht warten darf, und dem, was operativ zwar wünschenswert ist, aber sauber vorbereitet werden muss.
Gerade hier entscheidet sich viel. Nicht in der Präsentation des Zielbilds, sondern in den Arbeitsgesprächen dazwischen.
Ich halte diese persönliche Ebene nicht für weich oder nebensächlich. Sie ist ein harter Erfolgsfaktor. Wenn die Zusammenarbeit zwischen den zentralen IT-Verantwortlichen funktioniert, lassen sich auch schwierige Themen sachlich bearbeiten. Wenn sie nicht funktioniert, wird jede technische Frage politisch.
Konzernlogik ist nicht falsch. Sie muss übersetzt werden
Nach einer Akquisition treffen oft unterschiedliche IT-Welten aufeinander.
Auf der einen Seite stehen Konzernanforderungen: Standardisierung, zentrale Steuerung, Security-Vorgaben, Compliance, Skaleneffekte, Auditfähigkeit und einheitliche Plattformen. Auf der anderen Seite steht eine Organisation, die möglicherweise schneller, lokaler, pragmatischer und weniger formal gearbeitet hat.
Die einfache Erzählung wäre: Konzern gleich schwerfällig, Mittelstand gleich agil.
Diese Erzählung ist bequem, aber zu billig.
Konzernlogik hat gute Gründe. Wer international skaliert, regulatorische Anforderungen erfüllen muss und viele Einheiten steuert, braucht Standards. Ohne verbindliche Architektur, Security-Baselines und Governance wird Komplexität irgendwann nicht mehr beherrschbar.
Gleichzeitig darf Konzernlogik nicht blind ausgerollt werden. Was in einer großen Organisation als Standard sinnvoll ist, kann in einer kleineren Einheit operativ überfordern, wenn Reihenfolge, Kapazität und lokale Abhängigkeiten nicht berücksichtigt werden.
Die häufigste PMI-Falle ist nicht falsche Technologie. Es ist Konzernlogik ohne Übersetzung: Standards werden eingeführt, bevor die Organisation sie tragen kann. Das erzeugt Widerstand — nicht weil Menschen veränderungsfeindlich sind, sondern weil die Reihenfolge falsch ist.
Die eigentliche Führungsaufgabe liegt deshalb in der Übersetzung.
Welche Vorgaben sind nicht verhandelbar? Wo gibt es Spielraum im Weg, aber nicht im Ziel? Welche Standards müssen sofort greifen, weil sie Risiken reduzieren? Und welche Veränderungen brauchen Vorbereitung, weil sie sonst mehr Schaden als Nutzen erzeugen?
Diese Differenzierung ist entscheidend. Integration scheitert selten daran, dass Standards grundsätzlich falsch sind. Sie scheitert häufiger daran, dass Standards ohne Kontext eingeführt werden.
Angemessen bedeutet hier nicht langsam. Es bedeutet wirksam.
Die ersten 100 Tage brauchen Prioritäten, keine Vollständigkeit
In Integrationsphasen entsteht schnell der Wunsch nach Vollständigkeit. Alles soll erfasst, bewertet, geplant und möglichst sofort entschieden werden.
Das ist verständlich, aber gefährlich.
Die ersten 100 Tage sollten nicht den Anspruch haben, jede Detailfrage final zu klären. Sie müssen vor allem die richtigen Prioritäten setzen und diese in einen belastbaren Projektplan übersetzen.
Dieser Plan muss konkret genug sein, um steuerbar zu werden. Welche Aufgaben stehen an? Welche Themen haben Priorität? Welche Abhängigkeiten gibt es zwischen IT, Finance, HR, Legal, Operations und anderen Workstreams? Wer ist verantwortlich? Wer entscheidet? Welche Risiken müssen sofort adressiert werden? Welche Themen können bewusst später kommen?
Ohne diese Klarheit bleibt Integration eine Sammlung guter Absichten. Mit ihr wird aus Unsicherheit ein steuerbares Programm.
Für mich stehen dabei fünf Themen im Vordergrund.
- Erstens: Stabilität im Betrieb. Das laufende Geschäft darf durch Integrationsaktivitäten nicht unnötig gefährdet werden. Gerade IT muss hier nüchtern bleiben. Nicht jede sinnvolle Zielarchitektur rechtfertigt ein operatives Risiko zum falschen Zeitpunkt.
- Zweitens: Sicherheit und Zugriffskontrolle. Identity, privilegierte Zugriffe, Netzwerkübergänge, externe Verbindungen und kritische Systeme gehören früh auf den Tisch. Nicht aus Misstrauen, sondern aus Verantwortung. Eine Akquisition verändert die Risikolage. Das muss aktiv gesteuert werden.
- Drittens: Transparenz über kritische Anwendungen und Abhängigkeiten. Viele Risiken liegen nicht in den großen Systemen, sondern in den kleinen, kaum sichtbaren Lösungen. Wer sie übersieht, bekommt später Probleme an Stellen, die im Managementbericht nie prominent wirkten.
- Viertens: Klare Entscheidungswege. In PMI-Programmen entstehen viele Schnittstellen. Ohne klare Zuständigkeiten wird jede Frage langsam. Wer darf entscheiden? Wer muss eingebunden werden? Wo braucht es Eskalation? Diese Fragen wirken banal, sparen aber enorm viel Reibung.
- Fünftens: Kommunikation. Nicht als Change-Folie, sondern als konkrete Orientierung für die Menschen. Was ändert sich? Was bleibt vorerst? Wer ist Ansprechpartner? Welche Entscheidungen sind getroffen, welche noch offen?
Das Ziel der ersten 100 Tage ist nicht, die Integration abzuschließen. Das Ziel ist, die Integration steuerbar zu machen. Dazu gehört ein Projektplan, der nicht nur Termine enthält, sondern Verantwortlichkeit schafft. Ein Plan, der Prioritäten sichtbar macht, Zielkonflikte benennt und verhindert, dass jeder Workstream isoliert optimiert.
Menschen sind kein Begleitfaktor der Transformation
In vielen IT-Transformationen wird viel über Systeme gesprochen und zu wenig über Menschen.
Das fällt besonders nach einer Akquisition auf. Für das Management ist die Transaktion vielleicht ein strategischer Schritt. Für viele Mitarbeitende ist sie erst einmal eine persönliche Unsicherheit.
Was passiert mit meiner Rolle? Werden unsere Systeme abgeschaltet? Gilt unsere bisherige Arbeit noch etwas? Werden Entscheidungen künftig woanders getroffen? Muss ich mich beweisen? Werde ich gehört?
Diese Fragen stehen selten offiziell auf der Agenda. Aber sie sind da.
IT-Führung muss das ernst nehmen. Nicht emotional übertreiben, aber auch nicht ignorieren. Wer in dieser Phase nur in Systemen, Tickets und Maßnahmenlisten denkt, verliert einen Teil der Organisation.
Gerade die lokalen IT-Teams tragen oft enormes Wissen. Sie kennen Ausnahmen, Abhängigkeiten, historische Entscheidungen, informelle Prozesse und reale Nutzerprobleme. Dieses Wissen ist in keiner CMDB vollständig abgebildet.
Wer lokale IT-Teams als reine Wissensquelle für die Migration behandelt und sie danach als Abzuwickelnde, verliert dieses Wissen — und zahlt es später in Form von operativen Problemen, die niemand vorhersehen konnte, weil niemand gefragt hat.
Wenn diese Menschen das Gefühl bekommen, nur noch abgewickelt zu werden, verliert die Integration Qualität. Wenn sie dagegen ernsthaft eingebunden werden, entsteht Geschwindigkeit. Nicht weil jeder Wunsch erfüllt wird, sondern weil Entscheidungen besser werden.
Das verlangt eine klare Haltung: Respekt vor dem Bestehenden, ohne Veränderung zu vermeiden. Anerkennung der geleisteten Arbeit, ohne jede gewachsene Struktur zu verteidigen. Offenheit im Dialog, ohne falsche Sicherheit zu versprechen.
Genau diese Balance ist schwer. Aber sie macht den Unterschied.
Nicht jede schnelle Entscheidung ist eine gute Entscheidung
PMI erzeugt Druck. Das ist normal. Es gibt Erwartungen, Synergieziele, Managementtermine, Auditfragen, Budgetlogiken und technische Abhängigkeiten.
Trotzdem sollte man Geschwindigkeit nicht mit Hektik verwechseln.
Eine schnelle Entscheidung ist gut, wenn sie auf ausreichender Klarheit basiert. Sie ist gefährlich, wenn sie nur getroffen wird, damit etwas entschieden ist.
In der IT kann eine falsche Reihenfolge teuer werden. Eine zu frühe Migration kann Prozesse destabilisieren. Eine zu harte Standardisierung kann lokale Besonderheiten zerstören, bevor man sie verstanden hat. Eine zu späte Security-Integration kann unnötige Risiken offenlassen. Eine unklare Kommunikationslinie kann Vertrauen beschädigen, selbst wenn die technische Maßnahme richtig ist.
Deshalb braucht Integration Führung, nicht nur Projektmanagement.
Projektmanagement sorgt dafür, dass Aufgaben verfolgt werden. Führung sorgt dafür, dass die richtigen Dinge in der richtigen Reihenfolge passieren. Sie hält Spannung aus. Sie erklärt Zielkonflikte. Sie entscheidet, wo Tempo nötig ist und wo Sorgfalt wichtiger ist.
Das ist in den ersten 100 Tagen besonders relevant, weil viele Weichen gestellt werden, bevor alle Informationen vollständig vorliegen. Perfekte Sicherheit gibt es nicht. Aber es gibt bessere und schlechtere Entscheidungslogik.
Was am Ende wirklich zählt
Die ersten 100 Tage nach einer Akquisition entscheiden selten über jedes System. Aber sie prägen, wie die weitere Integration erlebt wird.
Wird Integration als Übernahmeprogramm empfunden oder als professionell geführter gemeinsamer Prozess? Entsteht Vertrauen zwischen den handelnden Personen? Werden Risiken offen angesprochen? Werden Menschen eingebunden, ohne Entscheidungsfähigkeit zu verlieren? Wird Konzernlogik sinnvoll übersetzt oder nur weitergereicht?
Für mich ist das der Kern von IT-Transformation nach einer Akquisition: Man muss gleichzeitig stabilisieren, verstehen, priorisieren, planen und führen.
Wer nur migriert, greift zu kurz.
Wer nur harmonisiert, übersieht die Organisation.
Wer nur kommuniziert, aber nicht entscheidet, verliert Tempo.
Und wer nur entscheidet, ohne zuzuhören, verliert Vertrauen.
Die ersten 100 Tage zählen nicht, weil danach alles entschieden ist. Sie zählen, weil die Organisation in dieser Phase sehr genau beobachtet, wie Integration tatsächlich funktioniert.
Nicht auf der Folie. Im Alltag. In den Entscheidungen, die unter Druck getroffen werden. In der Frage, ob Risiken offen angesprochen oder wegmoderiert werden. Darin, ob Menschen das Gefühl bekommen, Teil eines gemeinsamen Prozesses zu sein — oder abgewickelt zu werden.
Dieser Eindruck prägt die nächsten Jahre stärker als jede Zielarchitektur.
