Ein neues MES, eine LAN-Erneuerung oder eine OT/IT-Integration scheitert selten an der Technik allein. Kritisch wird es, wenn ein Pilotwerk erfolgreich läuft und anschließend unter Zeitdruck auf zehn, zwanzig oder fünfzig Werke übertragen werden soll. Wer einen Factory-IT-Rollout planen will, braucht deshalb mehr als einen Terminplan. Entscheidend sind ein belastbares Betriebsmodell, klare Entscheidungsrechte und eine Architektur, die lokale Produktionsrealität kontrolliert abbildet.
Der zentrale Gegensatz lautet: Ein Pilot beweist, dass etwas funktionieren kann. Ein Rollout beweist, dass es wiederholbar funktioniert. Genau zwischen diesen beiden Anforderungen verlieren viele Programme Zeit, Budget und Akzeptanz auf dem Shopfloor.
Factory-IT-Rollout planen heißt Variabilität beherrschen
Produktionswerke sind keine identischen Kopien. Selbst innerhalb eines Konzerns unterscheiden sich Maschinenalter, Netzwerksegmente, Schichtmodelle, lokale Lieferanten, Prozessreife und regulatorische Anforderungen. Ein globales Template ignoriert diese Unterschiede nicht. Es entscheidet bewusst, welche Abweichungen zulässig sind und welche nicht.
Ohne diese Entscheidung entsteht schleichend ein Sonderlösungsportfolio. Werk A benötigt eine andere Schnittstelle, Werk B möchte eigene Benutzerrollen, Werk C hält am lokalen Reporting fest. Jede Ausnahme mag einzeln plausibel wirken. In Summe erhöhen sie Testaufwand, Supportkosten, Cyber-Risiken und die Dauer jedes weiteren Go-Lives.
Die richtige Frage lautet daher nicht: „Können wir das lokale Bedürfnis umsetzen?“ Sondern: „Ist diese Abweichung geschäftskritisch, wiederverwendbar und langfristig betreibbar?“ Nur dann gehört sie in den Standard. Alles andere wird dokumentiert, bewertet und über eine kontrollierte Ausnahmeentscheidung behandelt.
Vom Pilotprojekt zum skalierbaren Rollout-Modell
Ein belastbarer Rollout beginnt mit einer ehrlichen Pilotbewertung. Nicht nur die technische Abnahme zählt. Das Programm muss verstehen, welche manuellen Eingriffe nötig waren, welche Experten permanent verfügbar sein mussten und welche Probleme erst nach dem Go-Live sichtbar wurden. Wenn der Pilot nur durch Dauerpräsenz des Kernteams stabil blieb, ist er kein skalierbares Modell.
Das Zielbild sollte als sogenanntes Golden Template vorliegen. Darin werden Architektur, Sicherheitsvorgaben, Integrationsmuster, Stammdatenlogik, Testfälle, Betriebsprozesse und Schulungsunterlagen verbindlich beschrieben. Für MES-Programme gehören beispielsweise Traceability, elektronische Arbeitsanweisungen, OEE-Daten, ERP-Integration und die Anbindung von PLC- oder SCADA-Ebenen in diese Betrachtung.
Ein Golden Template ist jedoch kein statisches Dokument. Nach jeder Rollout-Welle muss das Programm entscheiden, welche Erkenntnisse in den Standard zurückfließen. Andernfalls wiederholt sich derselbe Fehler im nächsten Werk. Diese Rückkopplung braucht einen festen Change-Prozess mit klarer fachlicher, technischer und wirtschaftlicher Bewertung.
Die Standortanalyse entscheidet vor dem Kick-off
Der häufigste Planungsfehler ist ein zu grobes Standortbild. Ein Werk wird als „ähnlich“ klassifiziert, weil Produktgruppe oder Region passen. Für Factory IT reicht das nicht. Vor der Detailplanung braucht jedes Werk einen strukturierten Readiness Check.
Erfasst werden müssen unter anderem der Zustand von LAN und WLAN, Segmentierung und NAC, Server- oder Edge-Kapazitäten, Schnittstellenlandschaft, Maschinenkonnektivität, Datenqualität, lokale Betriebsverantwortung und verfügbare Key User. Ebenso wichtig sind produktionsseitige Restriktionen: geplante Wartungsfenster, saisonale Spitzen, Werksferien, Kundenabrufe und Stillstandskosten.
Aus diesen Daten entsteht keine reine Ampel, sondern eine belastbare Entscheidungsgrundlage. Ein technisch gut vorbereitetes Werk ohne verfügbare Fachbereiche ist nicht rolloutbereit. Umgekehrt kann ein engagiertes Werk mit instabiler Infrastruktur keinen sicheren Go-Live tragen. Reife muss über mehrere Dimensionen bewertet werden.
Governance: Entscheidungen dort treffen, wo sie wirken
In internationalen Rollouts ist Governance kein Reporting-Ritual. Sie ist das Mittel, um Zielkonflikte rechtzeitig zu entscheiden. Global IT will Standardisierung, die Produktion will Verfügbarkeit, Cybersecurity fordert Risikominimierung und lokale Werke brauchen Handlungsfähigkeit. Ohne festgelegte Entscheidungswege eskalieren diese Konflikte zu spät.
Ein wirksames Modell trennt drei Ebenen. Das zentrale Programm verantwortet Template, Budgetrahmen, Architektur und Wellenplanung. Die Werke verantworten lokale Readiness, Ressourcen und die Umsetzung vereinbarter Maßnahmen. Ein fachlich und technisch besetztes Design Authority Board entscheidet verbindlich über Abweichungen, Schnittstellen und Standardänderungen.
Wichtig ist die Geschwindigkeit dieser Entscheidungen. Ein offener Architekturpunkt, der vier Wochen in Gremien liegt, blockiert oft Beschaffung, Build und Test parallel. Deshalb brauchen Entscheidungsgremien klare Mandate, Eskalationsfristen und eine nachvollziehbare Dokumentation. PMO-Arbeit schafft hier nicht mehr Folien. Sie schafft Verbindlichkeit, Transparenz und steuerbare Abhängigkeiten.
Rollout-Wellen nach Risiko statt nach Landkarte planen
Die intuitive Reihenfolge lautet oft: zuerst die größten Werke oder zuerst eine Region. Das kann richtig sein, muss es aber nicht. Die bessere Reihenfolge kombiniert Geschäftsnutzen, technische Reife, Veränderungsbereitschaft und Risiko. Ein mittelgroßes, gut vorbereitetes Werk kann als erste Industrialisierungswelle wertvoller sein als ein großes Referenzwerk mit zwanzig Sonderfällen.
Planen Sie die Wellen so, dass das Programm lernen kann, ohne die Produktion zu gefährden. Zwischen zwei Go-Lives muss genug Zeit liegen, um Defekte zu analysieren, Standards anzupassen und das Support-Modell zu stabilisieren. Zu kurze Abstände erzeugen scheinbar hohes Tempo, verlagern aber ungelöste Probleme in die nächste Welle.
Für jede Welle sollten mindestens fünf Kriterien verbindlich erfüllt sein:
- Infrastruktur, Security und technische Abhängigkeiten sind nachweislich bereit.
- Geschäftsprozesse, Stammdaten und Schnittstellen sind end-to-end getestet.
- Key User, Schichtverantwortliche und lokaler Support sind einsatzfähig.
- Cutover, Fallback und Hypercare besitzen benannte Verantwortliche.
- Produktionsfenster und akzeptierte Betriebsrisiken sind vom Werk freigegeben.
Ein Go-Live ohne diese Nachweise ist keine Beschleunigung. Er ist eine Verlagerung von Risiko in den laufenden Betrieb.
Cutover und Hypercare als Produktionsschutz gestalten
Der Cutover darf nicht als letzte technische Checkliste behandelt werden. In Factory IT berührt er Materialfluss, Qualitätsdaten, Maschinenanbindung und Produktionsfreigaben. Deshalb müssen die Szenarien gemeinsam mit Produktion, Qualität, Instandhaltung, IT und gegebenenfalls externen Anlagenlieferanten durchgespielt werden.
Ein belastbarer Fallback-Plan beantwortet konkrete Fragen: Wie lange kann das Werk mit manuellen Prozessen arbeiten? Welche Daten müssen nacherfasst werden? Wann wird zurückgeschwenkt? Wer entscheidet bei widersprüchlichen Kennzahlen? Besonders bei Traceability-relevanten Abläufen darf es keinen Interpretationsspielraum geben.
Nach dem Go-Live beginnt die Phase, die über Akzeptanz entscheidet. Hypercare braucht ein transparentes Ticket-Triage-Modell mit Prioritäten, Service Levels und täglichen Lagebildern. Nicht jedes Ticket ist kritisch. Aber ein kleiner Fehler an einer Station kann einen ganzen Prozessschritt blockieren. Die Priorisierung muss deshalb den Produktionsimpact abbilden, nicht nur die technische Fehlerklasse.
Messbar wird Erfolg über mehr als die Anzahl aktivierter Werke. Relevante Kennzahlen sind etwa Go-Live-Stabilität, ungeplante Produktionsunterbrechungen, Lösungszeit kritischer Tickets, Template-Abweichungen, Testabdeckung und die Zeit bis zur Übergabe in den Regelbetrieb. Diese Kennzahlen machen sichtbar, ob das Programm tatsächlich skaliert oder nur Termine erfüllt.
Vendor Management: Lieferanten auf das Zielsystem ausrichten
Factory-IT-Rollouts binden häufig Systemintegratoren, Netzwerkpartner, MES-Anbieter, Maschinenlieferanten und lokale Dienstleister ein. Das Risiko liegt selten in fehlender Expertise. Es liegt in Übergaben, unklaren Leistungsgrenzen und widersprüchlichen Annahmen.
Lieferantensteuerung muss daher auf prüfbaren Ergebnissen basieren: akzeptierte Designs, getestete Schnittstellen, dokumentierte Betriebsübergaben und nachweislich geschulte Teams. Ein Status „in Arbeit“ ist keine belastbare Steuerungsinformation. Entscheidend ist, welches Ergebnis bis wann unter welchen Abnahmekriterien vorliegt.
ITNB unterstützt solche Programme mit einer Kombination aus Projektsteuerung, PMO-Struktur und technischem Verständnis für Infrastruktur, MES und Shopfloor-Prozesse. Der Nutzen liegt nicht in zusätzlicher Koordination, sondern in einer Rollout-Logik, die Risiken früh sichtbar macht und Entscheidungen in die Umsetzung bringt.
Ein Factory-IT-Rollout gewinnt nicht dadurch, dass jedes Werk exakt gleich wird. Er gewinnt, wenn der Konzern einen klaren Standard konsequent schützt, notwendige lokale Unterschiede kontrolliert zulässt und jedes Go-Live den nächsten besser vorbereitet. So wird aus einem erfolgreichen Pilot keine teure Ausnahme, sondern ein steuerbares Transformationsprogramm.
