DevOps-Implementierung in der Fertigung: Ein praktischer Leitfaden für Operations-Teams

DevOps-Implementierung in einem Fertigungsunternehmen ist nicht dasselbe wie DevOps in einem Softwareunternehmen. Die Werkzeuge überschneiden sich. Die Prinzipien sind dieselben. Die Umgebung ist völlig anders.

In einem Softwareunternehmen wird ein fehlgeschlagenes Deployment zurückgerollt. In einer Fabrik stoppt ein fehlgeschlagenes Deployment eine Produktionslinie. Dieser Unterschied prägt jede Entscheidung: was automatisiert wird, was gegated wird, wie schnell man vorgeht und wer den Prozess verantwortet.

Dieser Leitfaden behandelt, was DevOps-Implementierung für Fertigungsunternehmen tatsächlich erfordert: die Herausforderung der OT/IT-Integration, das Umsetzungsframework und die Leistungskennzahlen, die darüber entscheiden, ob es funktioniert.

Was bedeutet DevOps im Fertigungskontext?

In der Softwarebranche ist DevOps die Praxis, Entwicklung und Betrieb in einer einzigen kontinuierlichen Delivery-Pipeline zu verbinden – schnellere Releases, schnellere Wiederherstellung, messbare Zuverlässigkeit.

In der Fertigung ist das Äquivalent die Integration von IT-Systemen (ERP, MES, Cloud-Anwendungen) mit OT-Systemen (SPS, SCADA, Industriesensoren) in einer einheitlichen Pipeline, in der Änderungen – Software, Konfiguration, Firmware – mit derselben Disziplin bereitgestellt, überwacht und zurückgerollt werden können, die auch im Software-Engineering gilt.

Das Ziel ist dasselbe: die Zeit zwischen einer Entscheidung und ihrer Auswirkung auf die Produktion verkürzen und das Risiko eines Fehlschlags dieser Auswirkung reduzieren.

Was sich ändert, ist die Randbedingung. OT-Systeme wurden für Stabilität und deterministische Leistung gebaut, nicht für kontinuierlichen Wandel. Wie Jeffrey Hojlo, Research Vice President bei IDC, festgestellt hat: "IT-Teams bewegen sich schneller in Richtung Veränderung als OT" – und genau dort scheitern die meisten DevOps-Implementierungen in der Fertigung.

Warum ist DevOps in der Fertigung schwer umzusetzen?

Drei strukturelle Herausforderungen gelten für nahezu jede Fertigungsumgebung.

1. Die OT/IT-Kluft ist ein Kulturproblem, nicht nur ein technisches

OT-Teams, die Ingenieure, die die Fabrikhalle betreiben, priorisieren vor allem Betriebszeit. IT-Teams priorisieren Geschwindigkeit und zentrale Governance. Das sind keine kompatiblen Standardhaltungen. DevOps erfordert eine gemeinsame Pipeline, gemeinsame Tools und gemeinsame Verantwortlichkeit. Dorthin zu gelangen erfordert organisatorischen Wandel, nicht nur ein neues CI/CD-Tool.

Laut Deloittes 2025 Smart Manufacturing Survey liegt die Verantwortung für nur 51 % der Smart-Manufacturing-Initiativen bei Operations-Führungskräften. 38 % liegen bei Technologie-Führungskräften. Diese gespaltene Verantwortung ist eine direkte Ursache für gescheiterte Implementierungen – kein einheitlicher Owner bedeutet keine einheitliche Pipeline.

2. Legacy-OT-Systeme wurden nicht für Konnektivität gebaut

SPS, SCADA-Systeme und industrielle Historians stammen aus einer Zeit vor Netzwerkkonnektivität als Designanforderung. Sie an eine DevOps-Pipeline anzubinden erfordert Protokollübersetzung, Edge-Gateways und eine Sicherheitsarchitektur, die die meisten Hersteller noch nicht aufgebaut haben. Deloitte fand heraus, dass 57 % der Hersteller Cloud Computing auf Anlagenebene nutzen, aber nur 29 % KI/ML operativ einsetzen. Die Infrastrukturebene existiert. Die Anwendungsebene nicht.

3. Das benötigte Talent ist intern nicht vorhanden

65–70 % der Hersteller lagern IT-, OT-, Data-Science- und Anwendungsentwicklungsrollen aus, so Deloittes 2025 Smart Manufacturing Survey. 69–72 % berichten von mittlerer bis erheblicher Schwierigkeit, qualifizierte Fachkräfte in den von DevOps benötigten Technologiebereichen einzustellen. Das ist kein vorübergehender Engpass. Es ist eine strukturelle Lücke zwischen dem, was Fertigungsbetriebe brauchen, und dem, was der verfügbare Talentpool bietet.

Wie implementiert man DevOps in einem Fertigungsunternehmen: Ein praktisches Framework

Die Umsetzung folgt vier Phasen. Jede Phase hat ein definiertes Ergebnis und eine definierte Randbedingung. Gehen Sie erst zur nächsten Phase über, wenn die aktuelle stabil ist.

Phase 1 – Bestandsaufnahme und Baseline (Wochen 1–8)

Erfassen Sie den aktuellen Zustand der OT- und IT-Systeme: was verbunden ist, was nicht, welche Protokolle im Einsatz sind und wo die Sicherheitsgrenzen liegen. Etablieren Sie Baseline-Kennzahlen anhand der vier DORA-Indikatoren: Deployment-Häufigkeit, Vorlaufzeit für Änderungen, Änderungsfehlerrate und mittlere Wiederherstellungszeit.

Elite-Organisationen deployen mehrmals täglich und erholen sich von Ausfällen in unter einer Stunde. Die meisten Fertigungsorganisationen starten mit Deployment-Zyklen, die in Monaten gemessen werden, und Wiederherstellungszeiten, die in Wochen gemessen werden. Die Lücke ist messbar. Sie zu messen ist der erste Schritt.

Ergebnis: Systemlandkarte des Ist-Zustands, DORA-Baseline-Kennzahlen, identifizierte Integrationspunkte.

Phase 2 – Pilot auf einer einzelnen Linie (Wochen 8–20)

Wählen Sie eine Produktionslinie mit der höchsten Instrumentierung und der geringsten Ausfallzeit-Sensibilität. Implementieren Sie eine einheitliche Datenpipeline, die OT-Sensoren mit einem IT-seitigen Monitoring-System verbindet. Führen Sie Versionskontrolle für Konfigurationsänderungen auf dieser Linie ein. Testen Sie Rollback-Verfahren.

Versuchen Sie in dieser Phase nicht, das Tooling in der gesamten Anlage zu standardisieren. Das Ziel ist ein funktionierendes Modell, keine Richtlinie. Der Pilot liefert die Belege, die die breitere Investition rechtfertigen.

Ergebnis: funktionierende OT/IT-Pipeline auf einer Linie, dokumentierte Deployment- und Rollback-Verfahren, erste DORA-Verbesserungsdaten.

Phase 3 – Skalierung über mehrere Linien (Wochen 20–36)

Wenden Sie das Pilotmodell auf weitere Produktionslinien an. Etablieren Sie einen funktionsübergreifenden OT/IT-Lenkungsausschuss mit operativer Verantwortung. Standardisieren Sie das ISA-95-Datenmodell über alle Linien hinweg, um Konsistenz sicherzustellen. Implementieren Sie eine industrielle DMZ und eine Zero-Trust-Architektur, um OT-Netzwerke von breiterer IT-Exposition zu isolieren.

Ergebnis: linienübergreifende Pipeline, einheitliches Data-Governance-Modell, etablierte Sicherheitsarchitektur.

Phase 4 – Optimieren und Messen (Wochen 36–52)

Schließen Sie den Kreis zwischen Produktionsdaten und Deployment-Entscheidungen. In dieser Phase sollten die DORA-Kennzahlen messbare Bewegung zeigen: sich verkürzende Vorlaufzeit für Änderungen, sinkende Änderungsfehlerrate. Setzen Sie klare Ziele für die nächsten 12 Monate.

Ergebnis: kontinuierlicher Verbesserungszyklus, definierte Leistungsziele, dokumentiertes Playbook für künftige Anlagen-Rollouts.

Wie sieht gute Performance aus?

Der DORA 2024 State of DevOps Report definiert vier Leistungsstufen. Elite-Performer machen nur 19 % aller Organisationen aus. Die Kennzahlen, die Elite von Low-Performern unterscheiden:

• Deployment-Häufigkeit – Elite: mehrmals täglich. Low: einmal im Monat bis einmal alle sechs Monate.
• Vorlaufzeit für Änderungen – Elite: unter einem Tag. Low: ein bis sechs Monate.
• Wiederherstellungszeit – Elite: unter einer Stunde. Low: eine Woche bis einen Monat.
• Änderungsfehlerrate – Elite: ~5 %. Low: 46–60 %.

Für Fertigungsbetriebe ist die Wiederherstellungszeit-Kennzahl operativ am bedeutsamsten. Eine Fabrik, die einen Monat braucht, um sich von einem fehlgeschlagenen Deployment zu erholen, betreibt kein DevOps. Sie betreibt Wasserfall mit neuem Namen.

Die Vorlaufzeit-Kennzahl übersetzt sich direkt in Wettbewerbsreaktionszeit – wie schnell eine Änderung auf dem Produktionsboden von der Entscheidung zum Deployment gelangt. Diese von Monaten auf Tage zu verkürzen, verändert, was operativ möglich ist.

Was sind die häufigsten Fehlerquellen bei DevOps-Rollouts in der Fertigung?

Es als IT-Projekt behandeln

DevOps in der Fertigung scheitert, wenn die IT es besitzt und die OT es nur toleriert. Die Pipeline erfordert operative Verantwortung. Wenn der COO oder der Operations-Direktor nicht für das Ergebnis verantwortlich ist, übersteht die Implementierung den ersten Produktionskonflikt zwischen Betriebszeit und Deployment-Geschwindigkeit nicht.

Bei Legacy-Systemen zu schnell vorgehen

Legacy-OT-Systeme mit Sicherheitslücken sind ein reales Risiko. Deloitte berichtet, dass 65 % der Hersteller operatives Risiko als ihre Hauptsorge einstufen und 69 % sich bei der Bedrohungserkennung auf Dritte verlassen. Eine Legacy-SPS ohne vorherige ordnungsgemäße Netzwerksegmentierung und Zugriffskontrollen an eine CI/CD-Pipeline anzubinden, führt genau das Risiko ein, das die Organisation reduzieren möchte.

Die Baseline-Messung überspringen

Ohne DORA-Baseline-Kennzahlen gibt es keine Möglichkeit, Fortschritt nachzuweisen. Implementierungen, die keine messbare Verbesserung zeigen können, verlieren innerhalb von 18 Monaten die organisatorische Unterstützung. Messen Sie ab Tag eins.

FAQ

Was ist DevOps-Implementierung in der Fertigung?

DevOps-Implementierung in der Fertigung ist der Prozess, IT- und OT-Systeme in eine einheitliche Deployment-Pipeline zu integrieren und dabei dieselbe Versionskontrolle, automatisierte Tests und kontinuierliche Delivery-Praktiken anzuwenden, die im Software-Engineering für Fabrikkonfiguration, Firmware und operative Softwareänderungen genutzt werden. Das Ziel ist eine schnellere, zuverlässigere Bereitstellung von Änderungen an Produktionssystemen.

Wie lange dauert die DevOps-Implementierung in einem Fertigungsunternehmen?

Eine vollständige DevOps-Implementierung in einer Fertigungsanlage dauert typischerweise 9–12 Monate nach einem Vier-Phasen-Ansatz: Bestandsaufnahme (Wochen 1–8), Einzellinien-Pilot (Wochen 8–20), Skalierung über mehrere Linien (Wochen 20–36) und Optimierung (Wochen 36–52). Pilotergebnisse sind innerhalb von 20 Wochen sichtbar.

Was sind die größten Herausforderungen bei der Implementierung von DevOps in der Fertigung?

Drei durchgängige Herausforderungen: die organisatorische OT/IT-Kluft, Legacy-Systeme, die nicht für Netzwerkkonnektivität gebaut wurden, und eine strukturelle Talentlücke in den Technologiefunktionen, die DevOps benötigt. Laut Deloittes 2025 Smart Manufacturing Survey lagern 65–70 % der Hersteller die Kerntechnologierollen aus, auf denen DevOps beruht.

Was ist eine DORA-Kennzahl und warum ist sie für die Fertigung wichtig?

DORA-Kennzahlen (DevOps Research and Assessment) sind vier standardisierte Indikatoren für DevOps-Performance: Deployment-Häufigkeit, Vorlaufzeit für Änderungen, Änderungsfehlerrate und mittlere Wiederherstellungszeit. Für die Fertigung ist die Wiederherstellungszeit-Kennzahl operativ am bedeutsamsten – sie misst, wie schnell der Betrieb auf ein fehlgeschlagenes Deployment reagieren und es beheben kann, bevor es den Produktionsoutput beeinträchtigt.

Wie unterscheidet sich DevOps in der Fertigung von Softwareunternehmen?

In der Softwarebranche wird ein fehlgeschlagenes Deployment zurückgerollt. In der Fertigung kann es eine Produktionslinie stoppen. Dieser Unterschied erfordert strengere Change-Gates, verpflichtende Rollback-Verfahren und OT-spezifische Sicherheitsarchitektur, bevor ein Deployment die Produktionsumgebung erreicht. Die Prinzipien sind identisch; Risikotoleranz und Tooling unterscheiden sich.