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. Ein Leitfaden für den Kulturwandel auf dem Shopfloor.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
Warum Kultur wichtiger ist als jedes Tool
Die meisten DevOps-Transformationen scheitern nicht an der Technologie. Jenkins lässt sich installieren, Pipelines lassen sich bauen, Container lassen sich orchestrieren. Was sich nicht installieren lässt, ist Vertrauen. Was sich nicht konfigurieren lässt, ist Zusammenarbeit.
In industriellen Umgebungen wird das noch deutlicher: Hier treffen zwei Welten aufeinander, die unterschiedliche Sprachen sprechen, unterschiedliche Prioritäten haben und unterschiedliche Identitäten mitbringen. 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 der einen oder anderen Seite zu opfern. Das ist anspruchsvoll. Aber es ist machbar.
Die zentrale Erkenntnis
Laut dem State of DevOps Report korreliert Unternehmenskultur stärker mit Software-Delivery-Performance als jedes einzelne Tool oder jede einzelne Praktik. Teams mit hoher psychologischer Sicherheit deployen 2x häufiger und erholen sich 3x schneller von Ausfällen.
Die 5 Säulen der DevOps-Kultur — industriell gedacht
Die CALMS-Framework-Säulen (Culture, Automation, Lean, Measurement, Sharing) bilden das Fundament jeder DevOps-Kultur. Im industriellen Kontext bekommt jede Säule eine besondere Bedeutung.
Collaboration
Zusammenarbeit über Silos hinwegIT- und OT-Teams arbeiten nicht nebeneinander, sondern miteinander. Gemeinsame Ziele, gemeinsame Verantwortung, gemeinsame Retrospektiven.
Psychological Safety
Psychologische SicherheitFehler werden als Lernchance behandelt, nicht bestraft. Wer einen Fehler meldet, wird geschützt — nicht bloßgestellt.
Continuous Improvement
Kontinuierliche VerbesserungNicht Perfektion ist das Ziel, sondern stetige, messbare Verbesserung. Kleine Schritte, häufiges Feedback, schnelle Iterationen.
Measurement
Datenbasierte EntscheidungenBauchgefühl wird durch Metriken ersetzt. Lead Time, Deployment Frequency, Change Failure Rate und Mean Time to Recovery (DORA-Metriken).
Sharing
Wissen teilenWissen ist kein Machtfaktor, sondern ein Multiplikator. Dokumentation, Tech Talks, Pair Programming, Communities of Practice.
Kulturelle Reifestufen: Wo steht Ihre Organisation?
Kulturwandel ist kein Schalter, sondern ein Spektrum. Diese fünf Stufen helfen Ihnen, den Ist-Zustand einzuordnen und realistische Ziele zu setzen.
Ad-hoc
Keine definierten Prozesse. Wissen in einzelnen Köpfen. Manuelle Deployments. Schuldzuweisungen bei Fehlern.
Managed
Grundlegende Prozesse definiert. Erste Automatisierung. IT und OT sprechen miteinander, aber arbeiten getrennt.
Defined
Standardisierte Prozesse. CI/CD-Pipelines im Einsatz. Cross-funktionale Teams beginnen sich zu formen.
Measured
Metriken steuern Entscheidungen. Feedback-Loops sind kurz. Kontinuierliche Verbesserung ist Routine.
Optimizing
Experimentierkultur. Teams optimieren autonom. Innovation wird belohnt. IT und OT sind eins.
5 Anti-Patterns: So scheitert DevOps-Kultur garantiert
Aus über 100 Projekten kennen wir die häufigsten Fallen. Erkennen Sie Ihre Organisation wieder?
„DevOps ist ein Tool-Problem"
„Wir haben jetzt ein DevOps-Team"
„Die OT-Seite macht nicht mit"
„Management hat es angeordnet"
„Automatisierung ersetzt Menschen"
Konkrete Praktiken: DevOps-Kultur im Alltag
Kultur entsteht durch Gewohnheiten, nicht durch Absichtserklärungen. 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.
Die Rolle der Führung: 5 Prinzipien
Kulturwandel scheitert oder gelingt an der Führung. Nicht weil Führungskräfte alles entscheiden müssen — sondern weil sie den Rahmen setzen, in dem Veränderung möglich wird.
Vorleben, nicht anordnen
Führungskräfte nutzen selbst die Tools, nehmen an Retrospektiven teil, geben eigene Fehler zu. Kultur wird kopiert, nicht dekretiert.
Schutzraum schaffen
Pilotprojekte von übermäßiger Kontrolle und Berichtspflicht abschirmen. Dem Team Raum geben, neue Arbeitsweisen auszuprobieren — ohne Angst vor Konsequenzen.
Erfolge sichtbar machen
Kleine Siege feiern und kommunizieren. „Das Team hat die Deployment-Zeit von 3 Tagen auf 2 Stunden reduziert" — konkret, messbar, nachvollziehbar.
Widerstände ernst nehmen
Widerstand ist kein Feind, sondern ein Signal. Zuhören, verstehen, adressieren. Oft steckt hinter „Das funktioniert bei uns nicht" eine berechtigte Sorge.
Langfristig denken
Kulturwandel braucht Monate, nicht Wochen. Rückschläge einplanen, Geduld bewahren. Der Weg von Stufe 1 zu Stufe 3 dauert typischerweise 12–18 Monate.
Psychologische Sicherheit: Der unterschätzte Hebel
Amy Edmondson, Professorin an der Harvard Business School, definiert psychologische Sicherheit als „die geteilte Überzeugung, dass das Team sicher ist für zwischenmenschliche Risikobereitschaft". Konkret: Kann ich einen Fehler zugeben, ohne bestraft zu werden? Kann ich eine Idee äußern, ohne ausgelacht zu werden?
In der OT-Welt ist das besonders kritisch. Ein Fehler an einer Produktionsanlage kann Personenschäden verursachen. Die natürliche Reaktion vieler Organisationen: strenge Kontrolle, Dokumentationspflicht, Bestrafung bei Fehlern. Das Ergebnis: Fehler werden vertuscht statt gemeldet.
Blameless Post-Mortem: Die Kernpraktik
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.
Fazit: Kultur ist kein Soft-Thema — sie ist der Wettbewerbsvorteil
DevOps-Kultur in der Industrie aufzubauen ist die anspruchsvollste und gleichzeitig wirkungsvollste Investition, die Sie tätigen können. Tools können kopiert werden, Prozesse können nachgebaut werden — aber eine Kultur der Zusammenarbeit, des Vertrauens und der kontinuierlichen Verbesserung ist Ihr nachhaltiger Wettbewerbsvorteil.
Starten Sie nicht mit dem großen Kulturwandel-Programm. Starten Sie mit einem cross-funktionalen Pilotteam, einem gemeinsamen Standup und einem Blameless Post-Mortem. Messen Sie die Ergebnisse. Feiern Sie die Erfolge. Und lassen Sie die Kultur wachsen.
Denken Sie daran: Die Maschinenbauer, die heute eine DevOps-Kultur aufbauen, werden morgen schneller, sicherer und resilienter liefern als ihre Wettbewerber. Nicht weil sie bessere Tools haben — sondern weil ihre Menschen besser zusammenarbeiten.
DevOps-Kultur-Workshop für Ihr Team
Wo steht Ihre Organisation kulturell? In einem eintägigen Workshop analysieren wir gemeinsam Ihre Ist-Situation, identifizieren die größten Hebel und entwickeln einen pragmatischen Fahrplan für Ihren Kulturwandel.
Häufig gestellte Fragen zur DevOps-Kultur in der Industrie
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.
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.
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.
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.
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.
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.
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.
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.
Bereit für den nächsten Schritt?
Vereinbaren Sie ein kostenloses Erstgespräch — wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Erstgespräch buchen