Ein geplanter Switch-Tausch im Produktionswerk dauert auf dem Papier vier Stunden. In der Realität stoppen ein fehlendes Rack-Layout, unklare VLAN-Zuordnungen und ein nicht abgestimmtes Wartungsfenster die Umsetzung. Genau deshalb sind die 10 Risiken bei Netzwerkinfrastrukturprojekten kein theoretisches PMO-Thema. Sie entscheiden darüber, ob ein Rollout kontrolliert in Betrieb geht oder ob er Produktion, Logistik und Kundenbetrieb beeinträchtigt.
Netzwerkinfrastruktur ist längst nicht mehr nur die technische Basis der IT. In Factory IT, FTTH-Rollouts, Energieinfrastruktur oder internationalen Standortmigrationen verbindet sie Geschäftsprozesse, OT-Systeme, Security und Betriebsverantwortung. Wer Risiken erst im Change Advisory Board oder während der Cutover-Nacht erkennt, hat bereits Zeit, Budget und Handlungsspielraum verloren.
Warum Netzwerkrisiken früh in die Steuerung gehören
Ein Infrastrukturprojekt scheitert selten an einem einzelnen Router oder einer fehlerhaften Konfiguration. Kritisch wird die Kombination: Abhängigkeiten sind nicht transparent, Verantwortlichkeiten verlaufen über mehrere Teams, Liefertermine verschieben sich und der Betrieb hat keine belastbare Rückfalloption.
Die richtige Gegenmaßnahme ist daher keine längere Risikoliste. Entscheidend ist ein Steuerungsmodell, das technische Risiken mit Terminplan, Lieferantensteuerung, Betriebsfreigabe und Entscheidungswegen verbindet. Risikomanagement muss in jedem Workstream sichtbar sein – nicht als Statusfolie für das Steering Committee, sondern als konkrete Grundlage für Entscheidungen.
10 Risiken bei Netzwerkinfrastrukturprojekten im Enterprise
1. Unklare Ausgangslage und schlechte Bestandsdaten
Viele Projekte starten mit Netzplänen, die nicht mehr dem tatsächlichen Zustand entsprechen. Dokumentationen zeigen alte Uplinks, vergessene Switches oder nicht mehr nachvollziehbare Portbelegungen. Besonders an gewachsenen Standorten ist das normal – aber kein Grund, die Planung darauf aufzubauen.
Vor Design Freeze und Beschaffung braucht das Projekt einen validierten Ist-Stand: physische Infrastruktur, IP-Adressierung, VLANs, Routing, Firmware, Abhängigkeiten und kritische Endgeräte. Ein gezielter Site Survey kostet Zeit. Ohne ihn wird diese Zeit später als ungeplanter Stillstand deutlich teurer.
2. Nicht erkannte Abhängigkeiten zu OT und Fachanwendungen
Ein Büro-LAN lässt sich anders migrieren als die Netzwerkinfrastruktur einer Fertigung. MES, SCADA, Maschinensteuerungen, Barcode-Scanner, Kameras, Zeiterfassung und Lagertechnik reagieren oft empfindlich auf Änderungen bei Latenz, Multicast, Port Security oder IP-Adressen.
Das Risiko steigt, wenn IT und OT getrennte Planungen verfolgen. Für jeden Standort sollte deshalb klar sein, welche Systeme geschäftskritisch sind, wer sie fachlich freigibt und welche Tests vor dem Cutover erforderlich sind. Ein erfolgreiches Ping ist kein Nachweis für eine funktionierende Produktionsintegration.
3. Ein Design, das den Betrieb nicht mitdenkt
Ein technisch sauberes Target Design reicht nicht aus, wenn Monitoring, Incident-Prozesse, Ersatzteilkonzept und Betriebsdokumentation fehlen. Nach dem Go-live übernimmt häufig ein Operations-Team, das nicht an allen Designentscheidungen beteiligt war. Dann entstehen Verzögerungen bei Störungen und unnötige Eskalationen.
Betriebsfähigkeit ist ein eigenes Lieferobjekt. Dazu gehören eindeutige Ownership, Alarmierung, Runbooks, Zugangskonzepte, Konfigurations-Backups und eine klare Übergabe. Bei globalen Rollouts muss zusätzlich geklärt sein, welche Aufgaben zentral erfolgen und was beim lokalen Team bleibt.
4. Unterschätzte Lieferzeiten und Vendor-Abhängigkeiten
Hardwareverfügbarkeit, Lizenzen, SFP-Module, Racks oder Glasfaserkomponenten können den kritischen Pfad bestimmen. Das gilt besonders bei standardisierten Enterprise-Plattformen, bei denen ein vermeintlich kleines Zubehörteil die Inbetriebnahme blockiert.
Beschaffung darf daher nicht als administrativer Nebenprozess laufen. Ein belastbarer Plan trennt Long-Lead-Items von Standardmaterial, enthält bestätigte Liefertermine und definiert Alternativen. Bei Dienstleistern braucht es zudem klare Kapazitätszusagen, Abnahmekriterien und Eskalationswege. Ein Vendor-Status ohne belastbare Fakten ist keine Terminabsicherung.
5. Unrealistische Cutover-Planung
Die kritischste Nacht eines Projekts wird oft mit einer Ablaufplanung vorbereitet, die nur den Idealverlauf kennt. Dort fehlen Puffer für Zugangsprobleme, unerwartete Verkabelung, Konfigurationsfehler, Tests oder Entscheidungen außerhalb der regulären Arbeitszeit.
Ein belastbarer Cutover-Plan arbeitet mit klaren Go-/No-Go-Punkten. Er benennt für jeden Schritt Owner, Startbedingung, erwartetes Ergebnis, Eskalation und maximale Dauer. Ebenso wichtig: Das Business muss wissen, wann welche Services eingeschränkt sind. Ein Wartungsfenster ist nur dann real, wenn alle betroffenen Bereiche es akzeptiert haben.
6. Fehlender oder ungetesteter Rollback
Rollback wird häufig erwähnt, aber nicht geplant. Eine alte Konfiguration liegt irgendwo bereit, Backups wurden nicht geprüft und niemand hat entschieden, bis zu welchem Zeitpunkt eine Rückkehr technisch noch möglich ist. Im Ernstfall führt das zu Diskussionen statt zu kontrolliertem Handeln.
Ein guter Rollback ist konkret: Welche Komponenten werden zurückgesetzt? Wer trifft die Entscheidung? Wie lange dauert die Wiederherstellung? Welche Daten oder Konfigurationen könnten verloren gehen? Bei hochkritischen Standorten kann ein Parallelbetrieb sinnvoll sein. Das erhöht Aufwand und Kosten, reduziert aber das Ausfallrisiko erheblich.
7. Security wird zu spät integriert
NAC, Segmentierung, Firewall-Regeln, Admin-Zugriffe und Zertifikate sind keine Nacharbeiten nach der Migration. Werden Security-Anforderungen erst kurz vor Go-live eingebracht, entstehen ungeprüfte Ausnahmen oder Terminverschiebungen.
Der Zielkonflikt ist bekannt: Security fordert Kontrolle, der Betrieb fordert Geschwindigkeit. Gute Projektsteuerung löst ihn nicht durch pauschale Freigaben, sondern durch risikobasierte Entscheidungen. Kritische Zonen, privilegierte Zugänge und OT-Segmente benötigen eine andere Prüfungstiefe als ein isoliertes Testnetz.
8. Unklare Rollen in der Multi-Stakeholder-Umgebung
In großen Infrastrukturprogrammen arbeiten Network Engineering, Security, Workplace, Facility Management, lokale IT, externe Provider und Fachbereiche zusammen. Wenn RACI-Modelle fehlen oder nur auf hoher Ebene existieren, bleibt im Cutover offen, wer tatsächlich entscheiden und handeln darf.
Projektleitung braucht hier mehr als ein Organigramm. Nötig sind verbindliche Verantwortlichkeiten pro Lieferobjekt, regelmäßige Entscheidungsrunden und ein Eskalationspfad mit Reaktionszeiten. Besonders wirksam sind risikoorientierte Workstream-Reviews: Was blockiert den Termin, wer löst es bis wann und welche Managemententscheidung ist erforderlich?
9. Fehlende Teststrategie und unklare Abnahme
Ein Netzwerk kann technisch verfügbar sein und dennoch die Anforderungen des Standorts verfehlen. Ohne abgestimmte Testfälle werden häufig nur Connectivity und Grundfunktionen geprüft. Fachliche Prozesse, Redundanzverhalten, Failover und Performance unter Last bleiben außen vor.
Die Abnahme sollte bereits während der Planung definiert werden. Dazu zählen Testumfang, Testdaten, Verantwortliche, Nachweise und akzeptierte Restmängel. Bei Produktionsstandorten sind Tests nach Schichtwechseln oder während realer Prozesslast oft aussagekräftiger als eine isolierte Prüfung im Wartungsfenster.
10. Risiken werden berichtet, aber nicht entschieden
Das gefährlichste Risiko ist ein Risikoregister ohne Konsequenz. Wenn rote Punkte über Wochen im Statusbericht stehen, aber weder Budget, Prioritäten noch Ressourcen angepasst werden, entsteht eine Scheinsicherheit. Das Projekt dokumentiert den Kontrollverlust, statt ihn zu verhindern.
Jedes Top-Risiko braucht daher einen Owner, eine Eintrittswahrscheinlichkeit, eine operative Gegenmaßnahme und ein Datum für die nächste Entscheidung. Wichtig ist die Verknüpfung mit dem Terminplan: Welche Meilensteine sind gefährdet, was kostet die Verzögerung und welche Option reduziert den Schaden am stärksten?
Risikosteuerung, die im Projektalltag funktioniert
Für Enterprise-Projekte hat sich ein einfaches Prinzip bewährt: Risiken werden nicht einmal monatlich gesammelt, sondern entlang der Lieferlogik gesteuert. In der Planungsphase stehen Ist-Aufnahme, Design-Abhängigkeiten und Beschaffung im Fokus. Vor dem Cutover dominieren Readiness, Security-Freigaben, Testnachweise und Rollback. Nach Go-live zählen Stabilisierung, Incident-Trends und vollständige Betriebsübergabe.
Ein kompaktes Risk Board mit den zehn bis fünfzehn wirklich entscheidenden Punkten ist wertvoller als eine Tabelle mit hundert Einträgen. Jede Zeile muss eine Managementfrage beantworten: Akzeptieren wir das Risiko, reduzieren wir es, verschieben wir den Termin oder investieren wir gezielt in eine Absicherung?
ITNB setzt in komplexen Infrastruktur- und Transformationsprojekten auf diese Verbindung aus technischer Detailtiefe und klarer Governance. Das Ziel ist nicht, Risiken vollständig zu eliminieren. Das wäre unrealistisch und oft unwirtschaftlich. Ziel ist, Risiken früh sichtbar zu machen, Entscheidungen rechtzeitig herbeizuführen und den Betrieb nicht zum Testfeld des Projekts zu machen.
Wer den nächsten Netzwerkrollout vorbereitet, sollte deshalb nicht zuerst nach dem detailliertesten Gantt-Chart fragen. Die entscheidende Frage lautet: Welche drei Annahmen würden unseren Termin oder Betrieb unmittelbar gefährden, wenn sie morgen falsch wären? Dort beginnt wirksame Projektkontrolle.
