DevOps-Kultur
in der Industrie.
So gelingt der Wandel.
Tools und Pipelines sind die einfache Seite von DevOps. Die schwierige Seite ist die Kultur: Zusammenarbeit, Vertrauen, Lernbereitschaft — besonders dort, wo IT und OT aufeinandertreffen.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
Kultur ist wichtiger
als jedes
Tool.
Die meisten DevOps-Transformationen scheitern nicht an der Technologie. Jenkins lässt sich installieren, Pipelines lassen sich bauen. Was sich nicht installieren lässt, ist Vertrauen. Was sich nicht konfigurieren lässt, ist Zusammenarbeit.
In industriellen Umgebungen wird das noch deutlicher: Der IT-Engineer, der „Move fast and break things" gelernt hat, trifft auf den OT-Engineer, für den jede ungeplante Änderung ein Sicherheitsrisiko ist.
DevOps-Kultur im industriellen Kontext bedeutet: Diese beiden Welten zu einer gemeinsamen Arbeitsweise zu verbinden — ohne die berechtigten Anliegen einer Seite zu opfern.
Quelle: State of DevOps Report · Comquent Projekterfahrungen
Unternehmenskultur korreliert stärker— Accelerate State of DevOps Report · Teams mit hoher psychologischer Sicherheit deployen 2× häufiger und recovern 3× schneller
mit Delivery-Performance als
jedes einzelne Tool.
Culture. Automation. Lean.
Measurement.
Sharing.
Die CALMS-Säulen bilden das Fundament jeder DevOps-Kultur. Im industriellen Kontext bekommt jede Säule eine besondere Bedeutung.
- /01
Collaboration
Zusammenarbeit über Silos hinweg
IT- und OT-Teams arbeiten nicht nebeneinander, sondern miteinander. Gemeinsame Ziele, gemeinsame Verantwortung, gemeinsame Retrospektiven.
Industrieller KontextIm Maschinenbau: Softwareentwickler und SPS-Programmierer sitzen im selben Sprint-Team — nicht in verschiedenen Gebäuden.
- /02
Psychological Safety
Psychologische Sicherheit
Fehler werden als Lernchance behandelt, nicht bestraft. Wer einen Fehler meldet, wird geschützt — nicht bloßgestellt.
Industrieller KontextKritisch in der OT: Wer einen Fehler an einer Produktionsanlage zugibt, riskiert in traditionellen Kulturen seine Karriere. DevOps dreht das um.
- /03
Continuous Improvement
Kontinuierliche Verbesserung
Nicht Perfektion ist das Ziel, sondern stetige, messbare Verbesserung. Kleine Schritte, häufiges Feedback, schnelle Iterationen.
Industrieller KontextKaizen-Prinzipien aus der Lean Production treffen auf DevOps — eine natürliche Verbindung, die Maschinenbauer sofort verstehen.
- /04
Measurement
Datenbasierte Entscheidungen
Bauchgefühl wird durch Metriken ersetzt. Lead Time, Deployment Frequency, Change Failure Rate und Mean Time to Recovery (DORA-Metriken).
Industrieller KontextOEE (Overall Equipment Effectiveness) und DORA-Metriken zusammendenken — so entsteht ein gemeinsames Bild der Leistungsfähigkeit.
- /05
Sharing
Wissen teilen
Wissen ist kein Machtfaktor, sondern ein Multiplikator. Dokumentation, Tech Talks, Pair Programming, Communities of Practice.
Industrieller KontextDer erfahrene SPS-Programmierer teilt sein Wissen mit dem DevOps-Engineer — und umgekehrt. Beide werden besser.
Fünf Stufen.
Ein Spektrum.
Kulturwandel ist kein Schalter. Diese fünf Stufen helfen Ihnen, den Ist-Zustand einzuordnen und realistische Ziele zu setzen.
- —Keine Versionskontrolle für SPS-Code
- —Deployments nur durch bestimmte Personen
- —„Das haben wir schon immer so gemacht"
- —Git für Steuerungscode eingeführt
- —Regelmäßige Abstimmungsmeetings IT/OT
- —Erste Build-Automatisierung
- —CI/CD für Steuerungscode produktiv
- —Gemeinsame Retrospektiven IT/OT
- —Blameless Post-Mortems etabliert
- —DORA-Metriken werden getrackt
- —A/B-Testing für Prozessverbesserungen
- —Wissensaustausch systematisiert
- —Teams treiben eigenständig Verbesserungen
- —Innovationszeit (20 %-Regel) etabliert
- —DevOps-Kultur ist selbstverständlich
Fünf Muster.
Garantiertes Scheitern.
- /01
„DevOps ist ein Tool-Problem"
SymptomJenkins installiert, aber Prozesse und Zusammenarbeit unverändert. Die Pipeline existiert, aber niemand vertraut ihr.
BesserTools sind Enabler, nicht die Lösung. Starten Sie mit den Prozessen und der Zusammenarbeit — die Tool-Entscheidung folgt.
- /02
„Wir haben jetzt ein DevOps-Team"
SymptomEin separates Team namens „DevOps" wird gegründet — und wird zum neuen Silo zwischen Entwicklung und Betrieb.
BesserDevOps ist kein Team, sondern eine Arbeitsweise. Integrieren Sie DevOps-Fähigkeiten in die bestehenden Teams.
- /03
„Die OT-Seite macht nicht mit"
SymptomIT treibt DevOps voran, OT fühlt sich übergangen. Widerstand wächst, weil OT-Spezifika ignoriert werden.
BesserOT-Expertise einbeziehen, OT-Constraints respektieren. Quick Wins suchen, die auch OT-Teams unmittelbar helfen.
- /04
„Management hat es angeordnet"
SymptomTop-Down-Verordnung ohne Erklärung des Warum. Teams führen Rituale durch, ohne den Sinn zu verstehen.
BesserKulturwandel braucht Leadership, nicht Management. Vorleben, erklären, ermöglichen — nicht anordnen.
- /05
„Automatisierung ersetzt Menschen"
SymptomAngst vor Jobverlust blockiert jede Veränderung. Teams sabotieren Automatisierungsinitiativen passiv.
BesserKlar kommunizieren: Automatisierung befreit von Routine und schafft Raum für wertschöpfende Arbeit.
Kultur entsteht
durch Gewohnheiten.
Nicht durch Absichten.
Diese Praktiken machen DevOps-Kultur greifbar — sortiert nach Häufigkeit.
Tägliche Praktiken
- Gemeinsames Standup
IT- und OT-Teammitglieder im selben Daily. 15 Minuten, gleiche Prioritäten.
- Pair Programming / Pair Commissioning
Ein Softwareentwickler und ein SPS-Programmierer arbeiten gemeinsam an einer Aufgabe.
- Shared On-Call
Gemeinsame Rufbereitschaft — nicht „IT-Problem" oder „OT-Problem", sondern „unser Problem".
Wöchentliche Praktiken
- Tech Talk Freitag
30 Minuten: Ein Teammitglied stellt ein Thema vor — OPC UA, Kubernetes, PROFINET, GitOps. Wechselnd IT und OT.
- Code Review Cross-Team
OT-Engineers reviewen IT-Code auf Praxistauglichkeit, IT-Engineers prüfen SPS-Code auf Struktur und Testbarkeit.
- Failure Friday
Bewusst über Fehler der Woche sprechen. Was ist schiefgegangen? Was haben wir gelernt? Keine Schuldzuweisungen.
Monatliche Praktiken
- Retrospektive
Was lief gut? Was können wir verbessern? Konkrete Maßnahmen definieren und nachverfolgen.
- Gemba Walk
IT-Teammitglieder besuchen die Produktion. OT-Teammitglieder besuchen die Entwicklungsabteilung. Kontext verstehen.
- Metriken-Review
DORA-Metriken und OEE gemeinsam reviewen. Zusammenhänge erkennen, Verbesserungen planen.
Fünf Prinzipien
für Führungskräfte.
Kulturwandel scheitert oder gelingt an der Führung — nicht weil sie alles entscheidet, sondern weil sie den Rahmen setzt.
- /01
Vorleben, nicht anordnen
Kultur wird kopiert, nicht dekretiert.
Führungskräfte nutzen selbst die Tools, nehmen an Retrospektiven teil, geben eigene Fehler zu.
- /02
Schutzraum schaffen
Raum für Experimente.
Pilotprojekte von übermäßiger Kontrolle und Berichtspflicht abschirmen. Dem Team Raum geben, neue Arbeitsweisen auszuprobieren — ohne Angst vor Konsequenzen.
- /03
Erfolge sichtbar machen
Konkret, messbar, nachvollziehbar.
Kleine Siege feiern und kommunizieren. „Das Team hat die Deployment-Zeit von 3 Tagen auf 2 Stunden reduziert" — so entsteht Sogwirkung.
- /04
Widerstände ernst nehmen
Widerstand ist ein Signal.
Zuhören, verstehen, adressieren. Oft steckt hinter „Das funktioniert bei uns nicht" eine berechtigte Sorge — keine Blockade.
- /05
Langfristig denken
Monate, nicht Wochen.
Kulturwandel braucht Zeit. Rückschläge einplanen, Geduld bewahren. Der Weg von Stufe 1 zu Stufe 3 dauert typischerweise 12–18 Monate.
Der unterschätzte
Hebel.
Amy Edmondson (Harvard) definiert psychologische Sicherheit als „die geteilte Überzeugung, dass das Team sicher ist für zwischenmenschliche Risikobereitschaft". Kann ich einen Fehler zugeben, ohne bestraft zu werden?
In der OT-Welt besonders kritisch: Ein Fehler an einer Produktionsanlage kann Personenschäden verursachen. Die natürliche Reaktion vieler Organisationen: strenge Kontrolle, Dokumentationspflicht, Bestrafung. Das Ergebnis: Fehler werden vertuscht statt gemeldet.
Blameless Post-Mortem.
Die Kernpraktik.
- /01
Fakten sammeln: Was ist passiert? Timeline erstellen, keine Interpretationen.
- /02
System analysieren: Welche Faktoren haben zum Vorfall beigetragen? Prozesse, Tools, Kommunikation.
- /03
Mensch schützen: Nicht „Wer hat den Fehler gemacht?", sondern „Warum war der Fehler möglich?"
- /04
Maßnahmen ableiten: Was ändern wir am System, damit dieser Fehler nicht wieder passieren kann?
- /05
Teilen: Das Post-Mortem wird veröffentlicht — als Lernressource für die gesamte Organisation.
Blameless Post-Mortems sind die wirkungsvollste Einzelmaßnahme für psychologische Sicherheit. Sie signalisieren: „Wir suchen Ursachen, nicht Schuldige." Das verändert über Zeit die gesamte Fehlerkultur — und damit die Innovationsfähigkeit der Organisation.
Was Kunden
wirklich fragen.
- Q.01
- Was ist das CALMS-Framework für DevOps-Kultur?
- CALMS steht für Culture, Automation, Lean, Measurement und Sharing — fünf Säulen, die eine erfolgreiche DevOps-Kultur definieren. Im industriellen Kontext wird jede Säule um spezifische Aspekte wie IT/OT-Zusammenarbeit, Kaizen-Prinzipien und OEE-Metriken erweitert.
- Q.02
- Was ist ein Blameless Post-Mortem?
- Ein Blameless Post-Mortem ist eine strukturierte Analyse von Vorfällen, die bewusst auf Schuldzuweisungen verzichtet und stattdessen Systemursachen untersucht. Die Methodik schützt Personen, fördert offene Kommunikation und verwandelt Fehler in dokumentiertes organisationales Lernen.
- Q.03
- Wie misst man DevOps-Kultur?
- DevOps-Kultur lässt sich über DORA-Metriken (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) quantifizieren, ergänzt durch qualitative Indikatoren wie Team-Surveys zur psychologischen Sicherheit. Die Kombination aus harten Metriken und weichen Faktoren liefert das vollständige Bild.
- Q.04
- Was ist psychologische Sicherheit und warum braucht DevOps sie?
- Psychologische Sicherheit bedeutet, dass Teammitglieder Risiken eingehen, Fehler zugeben und unbequeme Wahrheiten aussprechen können, ohne Konsequenzen zu fürchten. Ohne sie werden Fehler vertuscht, Verbesserungsvorschläge zurückgehalten und Innovationen blockiert.
- Q.05
- Warum scheitern viele DevOps-Transformationen?
- Die häufigste Ursache ist der Fokus auf Tools statt auf Kultur — Jenkins installieren ist einfach, Zusammenarbeit und Vertrauen aufbauen ist schwer. Weitere typische Fehler sind die Gründung eines separaten „DevOps-Teams" und Top-Down-Verordnungen ohne Erklärung des Warum.
- Q.06
- Wie startet man einen DevOps-Kulturwandel in der Fertigung?
- Starten Sie mit einem cross-funktionalen Pilotteam aus IT und OT, das an einem konkreten, gemeinsamen Projekt arbeitet. Führen Sie gemeinsame Standups, Retrospektiven und einen „Failure Friday" ein — und messen Sie die Ergebnisse mit DORA-Metriken.
- Q.07
- Was ist der Unterschied zwischen DevOps-Team und DevOps-Kultur?
- Ein „DevOps-Team" als separate Organisationseinheit ist ein Anti-Pattern, das ein neues Silo zwischen Entwicklung und Betrieb schafft. DevOps-Kultur hingegen bedeutet, DevOps-Fähigkeiten und -Denkweisen in alle bestehenden Teams zu integrieren.
- Q.08
- Welche Rolle spielt die Führung beim DevOps-Kulturwandel?
- Führungskräfte müssen die gewünschte Kultur aktiv vorleben, einen Schutzraum für Experimente schaffen und Erfolge sichtbar machen. Kulturwandel scheitert, wenn er nur angeordnet, aber nicht von der Führungsebene selbst praktiziert wird.
Ein Tag.
Ein Fahrplan.
Ihr Kulturwandel.
In einem eintägigen Workshop analysieren wir gemeinsam Ihre Ist-Situation, identifizieren die größten Hebel und entwickeln einen pragmatischen Fahrplan.
Verwandte Artikel
IT/OT-Kulturwandel in der Fertigung
Warum cross-funktionale Teams die größte DevOps-Herausforderung sind.
DevOps-Reifegrad messen & benchmarken
DORA-Metriken, Maturity Assessment und Value-Stream-Mapping.
Industrial DevOps: Der komplette Leitfaden
Was ist Industrial DevOps? CI/CD für cyber-physische Systeme und Industrie 4.0.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance