Ein einzelner Switch-Ausfall kann eine Produktionslinie stoppen, ein Lager vom ERP entkoppeln oder den Zugriff externer Teams auf kritische Systeme unterbrechen. Wer die Netzwerkinfrastruktur modernisieren will, sollte deshalb nicht bei Hardwarelisten anfangen. Entscheidend ist die Frage, welche Geschäfts- und Produktionsprozesse das Netzwerk in drei bis fünf Jahren sicher tragen muss – und wie die Umstellung ohne vermeidbare Betriebsrisiken gelingt.
In Konzernen scheitern Modernisierungen selten an fehlenden Technologien. Sie scheitern an unklaren Abhängigkeiten, parallel laufenden Initiativen, uneinheitlichen Standards und einem Rollout, der erst unter Zeitdruck konkret wird. Der Weg von reaktiver Störungsbeseitigung zu einer steuerbaren, skalierbaren Infrastruktur beginnt mit einer belastbaren Ausgangslage und einer Architektur, die auch organisatorisch betrieben werden kann.
Warum die bestehende Infrastruktur zum Transformationsrisiko wird
Legacy-Netzwerke wachsen häufig über Jahre projektweise. Ein Werk erhält zusätzliche Produktionsanlagen, ein Standort neue Büroflächen, ein Zukauf wird angebunden, Sicherheitsvorgaben ändern sich. Jede Maßnahme kann für sich sinnvoll sein. Zusammen entsteht jedoch oft eine Landschaft aus unterschiedlichen Switch-Generationen, lokalen Konfigurationen, nicht dokumentierten Sonderwegen und Abhängigkeiten, die niemand vollständig überblickt.
Das Risiko zeigt sich nicht erst bei einem Ausfall. Es zeigt sich, wenn die Einführung eines MES verzögert wird, weil Produktionsnetze nicht ausreichend segmentiert sind. Es zeigt sich bei der OT/IT-Integration, wenn Zugriffskonzepte und Verantwortlichkeiten offenbleiben. Und es zeigt sich bei Audits, wenn die Nachweise über Geräte, Ports, Firmwarestände oder Berechtigungen nur manuell und mit erheblichem Aufwand zusammengetragen werden können.
Eine veraltete Umgebung kostet damit nicht nur Budget für Ersatzteile und Supportverlängerungen. Sie bindet Spezialwissen, verlängert Changes und erhöht die Wahrscheinlichkeit, dass ein lokaler Eingriff übergreifende Folgen hat. Besonders in Produktion, Energie, Logistik und Telekommunikation ist das ein geschäftliches Risiko, nicht nur ein Infrastrukturthema.
Netzwerkinfrastruktur modernisieren heißt Zielbild definieren
Die Beschaffung neuer Komponenten ist ein Arbeitspaket, keine Strategie. Vor dem ersten Rollout braucht das Programm ein Zielbild, das fachliche Anforderungen, Sicherheitsarchitektur, Betriebsmodell und Migration zusammenführt. Ohne diese Klammer optimiert jedes Teilprojekt seinen Bereich – und produziert neue Sonderfälle.
Vom Inventar zur belastbaren Entscheidungsgrundlage
Am Anfang steht eine strukturierte Bestandsaufnahme. Sie erfasst nicht nur Hardware und Verträge, sondern auch Topologien, Datenflüsse, kritische Anwendungen, Schnittstellen zu OT-Systemen, Redundanzen und reale Betriebsverantwortung. Die zentrale Frage lautet: Was darf wie lange ausfallen, und welche Abhängigkeiten wären davon betroffen?
Ein sinnvoller Reifegradcheck bewertet beispielsweise Segmentierung, Netzwerkzugangskontrolle, Monitoring, Konfigurationsmanagement, Lifecycle-Status und Dokumentationsqualität. Das Ergebnis sollte keine endlose Geräteliste sein. Entscheider brauchen eine priorisierte Sicht: Welche Risiken verlangen sofortiges Handeln? Wo genügt eine geplante Erneuerung? Welche Maßnahmen sind Voraussetzung für Digitalisierungsprojekte?
Dabei gilt: Vollständigkeit ist wertvoll, darf aber keinen Stillstand erzeugen. Bei großen Standortlandschaften ist es oft sinnvoll, mit repräsentativen Werken oder kritischen Knoten zu starten und die Erhebung iterativ zu vervollständigen. Wichtig ist, Annahmen sichtbar zu machen und sie im Programm nachzuhalten.
Architekturprinzipien vor Produktauswahl
Ein tragfähiges Zielbild beantwortet konkrete Fragen. Wie werden Office-IT, Produktions-IT, Gastzugänge und externe Dienstleister getrennt? Wo sind zentrale Standards sinnvoll, wo brauchen Werke begründete lokale Ausnahmen? Wie wird der Zugriff von Maschinen, mobilen Geräten und Servicepartnern kontrolliert? Und wie lassen sich neue Standorte oder Linien anbinden, ohne jedes Mal eine eigene Architektur zu erfinden?
Segmentation, standardisierte Zonenmodelle, kontrollierte Identitäten und zentral sichtbare Telemetrie sind in vielen Umgebungen die richtigen Leitplanken. Die technische Ausgestaltung hängt jedoch vom Einsatz ab. Ein hochverfügbares Backbone in einem Telekommunikationsumfeld verfolgt andere Prioritäten als ein Produktionsnetz mit älteren Steuerungen. Pauschale Blaupausen sind hier teuer, weil sie Betriebsrealitäten ignorieren.
Auch Cloud-Anbindungen und Remote-Zugriffe gehören ins Zielbild. Sie dürfen nicht als nachträgliche Ausnahme behandelt werden. Wenn Daten aus dem Shopfloor in MES-, ERP- oder Analyseplattformen fließen, müssen Datenwege, Latenzen, Verantwortlichkeiten und Sicherheitskontrollen vor dem Rollout geklärt sein.
Der Rollout entscheidet über Akzeptanz und Nutzen
Die beste Zielarchitektur verliert an Wert, wenn sie nur als Präsentation existiert. Gerade in internationalen Konzernen ist eine Netzwerkmodernisierung ein Transformationsprogramm mit Betriebsfenstern, lokalen Stakeholdern, Vendoren und konkurrierenden Vorhaben. Der Rollout braucht deshalb eine klare Taktung statt improvisierter Einzelmigrationen.
Eine bewährte Sequenz beginnt mit einem Pilotstandort oder einer klar abgegrenzten Domäne. Dort werden Design, Runbooks, Abnahmeverfahren, Ersatzteilkonzept und Kommunikationswege unter realen Bedingungen geprüft. Erst wenn die Erkenntnisse in Standards überführt sind, folgt die Skalierung über weitere Standorte oder Wellen.
Für jede Welle müssen Scope, technische Voraussetzungen, Cutover-Plan, Rückfalloption und Abnahmekriterien verbindlich sein. Ein Cutover ohne getesteten Fallback ist kein mutiger Projektfortschritt, sondern eine nicht gesteuerte Risikowette. In produktionsnahen Bereichen sollte zudem früh mit Werksleitung, OT-Verantwortlichen, Instandhaltung und Security abgestimmt werden. Diese Gruppen bewerten Erfolg zu Recht nicht nach installierten Geräten, sondern nach sicherem Produktionsbetrieb.
Governance schafft Geschwindigkeit statt Bürokratie
Infrastrukturprogramme werden oft entweder zu locker oder zu schwer gesteuert. Bei zu wenig Governance entscheidet jeder Standort anders. Bei zu viel Governance warten Teams auf Freigaben, obwohl Standardentscheidungen längst getroffen sein müssten. Die Lösung liegt in klaren Entscheidungsrechten und einem Reporting, das Probleme früh sichtbar macht.
Ein wirksames PMO trennt strategische Entscheidungen von operativen Hindernissen. Architekturabweichungen, Budgetverschiebungen und Risiken mit Wirkung auf mehrere Standorte gehören in ein Steering. Fehlende Zugangsdaten, lokale Terminprobleme oder offene Vendor-Tickets müssen in einem operativen Takt aufgelöst werden. Werden beide Ebenen vermischt, verlieren Entscheider Zeit und Projektteams Orientierung.
Wenige Kennzahlen reichen aus, wenn sie belastbar sind: Fortschritt pro Migrationswelle, Anzahl kritischer Risiken, Change-Erfolgsquote, ungeplante Unterbrechungen, Anteil standardkonformer Standorte und Zeit bis zur Störungsbehebung. Ergänzend braucht es eine sichtbare Liste der Architekturabweichungen. Sonst werden Ausnahmen zur unsichtbaren neuen Norm.
Vendor-Management ist dabei ein eigener Erfolgsfaktor. Hersteller, Integratoren, lokale Dienstleister und interne Betriebsteams benötigen eindeutige Deliverables, Übergabepunkte und Eskalationswege. Wer lediglich Termine koordiniert, steuert noch kein Programm. Entscheidend ist, ob Abhängigkeiten geschlossen, Qualitätsnachweise erbracht und offene Risiken bis zum Cutover nachvollziehbar reduziert werden.
Security und Betrieb von Anfang an mitplanen
Viele Programme behandeln Security als Freigabe am Ende und den Betrieb als Empfänger der fertigen Lösung. Das erzeugt Nacharbeiten, Friktion und im schlimmsten Fall unsichere Übergänge. Security, Network Operations und OT-Verantwortliche müssen bereits die Zielarchitektur und die Migrationsmuster mitgestalten.
Das betrifft unter anderem Patch- und Firmwareprozesse, Monitoring-Schwellenwerte, Logging, Konfigurationssicherungen, Incident-Abläufe und den Umgang mit nicht standardfähigen Geräten. In Industrieumgebungen können ältere Anlagen bestimmte Protokolle oder Zugangskontrollen nicht ohne Weiteres unterstützen. Dann braucht es kompensierende Maßnahmen, eine dokumentierte Risikoentscheidung und einen realistischen Ablösepfad – nicht die Illusion einer vollständigen Standardisierung über Nacht.
Der Übergang in den Betrieb verdient dieselbe Aufmerksamkeit wie der technische Cutover. Runbooks, Verantwortungsmatrizen, Schulungen und ein stabiler Hypercare-Zeitraum machen den Unterschied zwischen einer erfolgreich installierten und einer dauerhaft steuerbaren Plattform. Erst wenn Betriebsteams Störungen erkennen, Änderungen kontrolliert durchführen und Kennzahlen verantworten können, ist die Modernisierung tatsächlich abgeschlossen.
Wo Investitionen zuerst wirken
Nicht jeder Standort muss gleichzeitig erneuert werden. Priorisieren Sie nach Geschäftsrisiko und Abhängigkeit, nicht nach Lautstärke einzelner Anforderungen. Kritische Produktionslinien, End-of-Support-Komponenten, stark wachsende Standorte oder Netzbereiche mit wiederkehrenden Incidents liefern oft den besten Startpunkt.
Gleichzeitig lohnt sich der Blick auf Skaleneffekte. Ein standardisiertes Design, wiederverwendbare Runbooks und ein einheitliches Abnahmeverfahren reduzieren den Aufwand pro weiterer Welle deutlich. Die anfängliche Investition in Architektur und Programmsteuerung wirkt damit über das gesamte Portfolio. Genau hier entsteht der Unterschied zwischen einem kostspieligen Hardwaretausch und einer kontrollierten Transformation.
ITNB unterstützt solche Vorhaben mit der Verbindung aus Infrastrukturverständnis, PMO-Struktur und operativer Umsetzungssteuerung. Das Ziel ist nicht, möglichst viele technische Maßnahmen zu starten. Das Ziel ist ein Programm, in dem Architektur, Risiko, Lieferfähigkeit und Business-Prioritäten in einem belastbaren Takt zusammenlaufen.
Beginnen Sie nicht mit der Frage, welche Komponenten ersetzt werden sollen. Beginnen Sie mit den Prozessen, die Ihr Netzwerk morgen zuverlässig ermöglichen muss – und richten Sie Architektur, Governance und Rollout konsequent darauf aus.
