Stakeholder-Management bei M&A: der Netzwerkarchitekt zwischen IT, OT und Deal-Team

Warum Netzintegration bei M&A ein Erwartungsproblem ist

Ein Synergieplan entsteht in der Regel, bevor jemand ins Netz geschaut hat. In den Unterlagen stehen Rechenzentren, die man zusammenlegt, eine gemeinsame Active-Directory-Struktur, ein konsolidiertes ERP, geteilte Internet-Anbindungen. Diese Ziele setzen voraus, dass das Netz eine austauschbare Ware ist, die man einfach verbindet. Genau das ist es nicht. Die Verschmelzung zweier gewachsener Infrastrukturen ist meist der langsamste, teuerste und riskanteste Teil einer Integration und der einzige, der die Produktion direkt gefährden kann.

Das Muster wiederholt sich: Der Architekt wird zu spät geholt, nämlich nach dem Signing, wenn die Synergieziele und die Zeitachse bereits verhandelt und dem Aufsichtsrat berichtet sind. Ab diesem Punkt gilt jede technische Wahrheit als schlechte Nachricht. Wer dann nur „das geht so nicht“ sagt, verliert. Die Aufgabe besteht darin, technische Realität in die Sprache von Risiko, Kosten und Zeit zu übersetzen und daraus einen Weg zu bauen, den alle Beteiligten mittragen können. Das ist Stakeholder-Management, ein wichtiges Thema in jedem Projekt.

Die Stakeholder-Landschaft: wer will was

Steakholder sind Interessengemeinschaften oder Personen mit einem Interesse an dem Projekt (positiv, wie negativ). Wer die Interessen nicht sauber trennt, verhandelt gegen ein Phantom. In einem typischen Deal stehen dem Architekten mindestens sechs Gruppen mit unvereinbaren Prioritäten gegenüber:

• Deal-Team und Integration Management Office (IMO): denken in Meilensteinen, Synergiebeträgen und Tag-1-Bereitschaft. Für sie ist „Netz verbinden“ eine Zeile im Plan, kein Projekt. Sie steuern über Kennzahlen und Termine.
• IT-Leitung (CIO): will standardisieren, Domänen zusammenführen, Lizenzen und Betriebskosten senken. Neigt dazu, OT als „noch mehr IT“ zu behandeln - mit den selben Werkzeugen, den selben Wartungsfenstern, derselben Änderungsgeschwindigkeit.
• OT und Produktion (Werkleitung, Instandhaltung, Automatisierung): wollen Stabilität, keine Ausfälle, keine erloschene Herstellerfreigabe. „Never touch a running system“ ist keine Bequemlichkeit, sondern gelernte Vorsicht. Diese Gruppe ist gegenüber IT-getriebenem Wandel oftmals grundsätzlich skeptisch.
• Security und CISO: wollen Sichtbarkeit, Segmentierung, kontrollierte Zugänge. Beim Zielunternehmen ist der Sicherheitszustand zunächst unbekannt, und das Unbekannte ist ihr größtes Problem.
• Recht und Compliance: denken an Datenschutz, an Übergangsdienstleistungsverträge und seit der Verschärfung durch NIS2 an persönliche Haftung der Geschäftsleitung.
• Betriebsrat: in Deutschland ein eigenständiger Stakeholder. Neue Fernzugriffe, Monitoring oder veränderte Arbeitsplätze berühren die Mitbestimmung - und werden zum Bremsklotz, wenn man sie erst nachträglich einbindet.

Hinzu kommen Externe: bestehende Dienstleister, Managed-Service-Provider und (bei einem Carve-out) die IT des Verkäufers, von der das Zielunternehmen zunächst weiter abhängt. Auch "nicht integrierte" Interessengruppen kannes geben: Man denke z.B. mal am Naturschutzveeine ooder ähnliches. Jede dieser Gruppen hat einen legitimen Anspruch. Der Fehler ist, sie alle mit derselben Botschaft anzusprechen oder gar zu ignorieren.

Der Grundkonflikt: Synergie-Tempo gegen OT-Stabilität

Der tiefste Widerspruch verläuft zwischen dem Wunsch nach schneller Verschmelzung und der Belastbarkeit der OT. Er lässt sich an einem einzigen Detail festmachen, das in fast jedem Deal auftaucht: überlappende Adressbereiche. Beide Unternehmen nutzen mit hoher Wahrscheinlichkeit den selben privaten IP-Addressraum, etwa 10.0.0.0/8 oder mehrere 192.168.x-Netze. Man kann zwischen zwei identischen Adressbereichen nicht einfach routen. NAT ist ein Notbehelf, der bei industriellen Protokollen, hart kodierten Adressen in SPS-Programmen und manchen Lizenzmechanismen bricht. Zudem gibt es diverse Geräte, bei denen die IP's nicht nur im ISO/OSI-Layer 3 sondern zeitgleich auch in der Applikation mit übermittelt werden. Da hilft dann auch kein NAT.

Dazu kommen Randbedingungen, die es in der reinen IT nicht gibt. Ein Eingriff in eine Steuerung kann die Herstellerfreigabe oder eine sicherheitsgerichtete Zertifizierung kosten. Ein Umnummerieren im laufenden Betrieb ist ausgeschlossen, weil sich eine Fertigungslinie nicht für ein Wochenende „mal eben“ abschalten lässt. Echtzeitanforderungen und funktionale Sicherheit dulden keine Experimente. Diese Punkte sind für die Produktion selbstverständlich und für das Deal-Team unsichtbar. Die Aufgabe des Architekten ist, sie sichtbar und quantifiziert zu machen. Nicht als Verweigerung, sondern als Aufwand, Risiko und Zeit, über die eine Geschäftsleitung entscheiden kann.

Due Diligence: was vor dem Closing geklärt sein muss

Idealerweise ist der Netzwerkarchitekt bereits in der technischen Due Diligence beteiligt - bevor unterschrieben wird. Denn was hier gefunden oder übersehen wird, landet später als Synergieannahme im Kaufpreis. Zu prüfen sind mindestens:

• Adressierung und Dokumentation: Gibt es einen belastbaren IP-Adressplan? Gerade für OT ist die Dokumentation erfahrungsgemäß lückenhaft oder veraltet.
• Segmentierungszustand: Ist die OT flach aufgebaut, oder existieren bereits Zonen? Ein flaches Werksnetz ist ein Kostentreiber, der die gesamte Integrationsdauer verändert.
• Abhängigkeiten vom Verkäufer: Welche Dienste? DNS, AD, Internet-Breakout, Fernwartung? Laufen diese bei einem Carve-out noch über die Muttergesellschaft? Der Umfang dieser Verflechtung bestimmt Länge und Preis des späteren Übergangs.
• Fernzugänge und Altsysteme: Wo hängen ungesicherte Wartungszugänge, wo laufen abgekündigte Betriebssysteme, die man nicht mehr patchen kann?

Das Ergebnis ist kein Prüfbericht für die Schublade, sondern eine realistische Integrations-Roadmap mit Aufwands- und Risikoschätzung. Genau damit gewinnt der Architekt Glaubwürdigkeit beim Deal-Team: Er liefert nicht Einwände, sondern eine Zahl, mit der sich planen lässt.

Tag 1 und die Übergangsphase: koppeln, nicht verschmelzen

Zum rechtlichen Closing wird oft eine minimale Tag-1-Konnektivität erwartet - gemeinsame E-Mail, ein paar geteilte Anwendungen -, obwohl noch nichts integriert ist. Die richtige Antwort ist eine kontrollierte Kopplung, keine Verschmelzung: eine über Firewalls geführte Transitzone, in der nur die wenigen tatsächlich nötigen Verbindungen freigeschaltet und überlappende Adressen an einem definierten Übergabepunkt per NAT behandelt werden. Alles andere bleibt getrennt.

Läuft ein Übergangsdienstleistungsvertrag (Transition Service Agreement), bezieht das Zielunternehmen weiter Leistungen vom Verkäufer. Der Architekt muss dafür eine saubere Demarkation und einen Ausstiegsplan entwerfen - sonst wird aus der befristeten Abhängigkeit ein Dauerzustand. Entscheidend ist eine früh kommunizierte Grenze: Die OT gehört nicht in den Tag-1-Umfang. OT-Integration ist ein mehrjähriges Programm, keine Aufgabe für die erste Woche. Wer das dem Deal-Team nicht rechtzeitig klarmacht, verhandelt später gegen ein Versprechen, das nie einlösbar war. Oft spricht man von CMO (Current Mode of Operation / Ist-Zustand), IMO (Interim Mode of Operation / Übergangsphase) und FMO (Future Mode of Operation / Ziel-Zustand).

Post-Merger-Integration: Segmentierung als Zielbild

Das häufigste Missverständnis der Integrationsphase ist das Bild vom einen, großen, verschmolzenen Netz. Das richtige Zielbild ist ein segmentiertes: ein gemeinsamer Kern für geteilte IT-Dienste, und jeder Standort, jedes Werk als eigene, kontrollierte Zone nach der Logik des Purdue-Modells und der Zonen-und-Conduits-Systematik der IEC 62443. Diese Umdeutung entschärft den Zeitdruck erheblich. Man muss nicht jedes Werk bis Tag 100 umnummerieren. Man definiert Zonen, Übergänge und eine schrittweise Migration.

Manche OT-Insel bleibt dabei über Jahre isoliert - und das ist eine gültige Architektur, kein Scheitern. Ein segmentiertes Ziel reduziert das Risiko, weil ein Vorfall in einem Unternehmensteil nicht auf den anderen überspringt. Es erfüllt zugleich die Anforderungen aus IEC 62443 und NIS2. Und es erlaubt dem Geschäft, Synergien dort zu heben, wo sie günstig sind: bei geteilten IT-Diensten, während es dort schützt, wo Veränderung teuer und gefährlich ist. Der Architekt verkauft der Geschäftsleitung damit nicht Verzicht, sondern eine Reihenfolge.

Wie man die Stakeholder tatsächlich mitnimmt

In der Praxis entscheidet weniger die Technik als die Kommunikation. Vier Grundsätze tragen durch fast jeden Deal:

1. Jede Gruppe in ihrer Sprache ansprechen. Dem Deal-Team liefert man Risiko, Kosten und Zeit; der OT geht es um Stabilität und Herstellerfreigabe; der IT um Standardisierung und Sicherheit. Dieselbe Entscheidung, drei Begründungen.
2. Ein gemeinsames Bild schaffen. Ein Zielarchitektur-Diagramm, auf das alle zeigen können, beendet mehr „verbindet das doch einfach“-Diskussionen als jede Wortmeldung. Wer auf dieselbe Grafik schaut, streitet konkreter.
3. Zielkonflikte offen an die Geschäftsleitung geben. Der Architekt entscheidet nicht über Risikoappetit. Er legt Optionen mit Aufwand und Konsequenz vor und lässt die Führung wählen. Anschließend wir die Entscheidung dokumentiert. Das schützt vor der Rolle des Sündenbocks.
4. OT früh einbinden und ihr Mitspracherecht über die eigenen Zonen geben. Wer die Produktion übergeht, erntet passiven Widerstand, der jedes Wartungsfenster kostet. Wer sie einbezieht, gewinnt die Leute, die als Einzige wissen, was ihre Anlagen wirklich vertragen. (Ist die Produktion nicht oftmals die wirkliche Cash-Cow?) Der Betriebsrat gehört bei neuen Zugriffen und Monitoring ebenso an den Tisch. Und bitte vorher, nicht nachher.

Fazit: die Architektur ist auch eine Haftungsfrage

Seit das NIS2-Umsetzungsgesetz in Deutschland gilt, erbt das kaufende Unternehmen mit dem Closing nicht nur die Netze, sondern auch die Sicherheitspflichten und die persönliche Haftung der Geschäftsleitung für den zusammengeführten Betrieb. Die Architekturentscheidungen, die unter M&A-Zeitdruck fallen, werden damit zu Compliance-Tatsachen. Eine segmentierte Zielarchitektur ist deshalb nicht nur sauberes Engineering, sondern die Voraussetzung dafür, das fusionierte Unternehmen nach NIS2 und IEC 62443 überhaupt verteidigen zu können. Das eigentliche Ergebnis des Netzwerkarchitekten bei einer Fusion ist kein Kabelplan. Es ist ein gemeinsames, realistisches Bild, auf das sich IT, OT und Deal-Team gleichermaßen verpflichten können.