Fehlerkultur.
Psychologische
Sicherheit im DevOps.
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.
DevOps-Kultur in der Industrie gelingt, wenn IT- und OT-Teams gemeinsame Ziele, gemeinsame Retrospektiven, psychologische Sicherheit und eine positive, blameless Fehlerkultur entwickeln. Das CALMS-Framework gibt den strukturellen Rahmen vor; entscheidend ist die konsequente Anwendung auf dem Shopfloor — nicht das Installieren weiterer Tools.
Stand: Juni 2026 · CALMS-Framework · DORA-Metriken · State of DevOps Report 2024
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. Die typischen Konfliktmuster beschreiben wir ausführlich im Artikel IT vs. OT: Warum Kultur entscheidet.
DevOps-Kultur im industriellen Kontext bedeutet: Diese beiden Welten zu einer gemeinsamen Arbeitsweise zu verbinden — ohne die berechtigten Anliegen einer Seite zu opfern. Wo Sie Ihr Team heute einordnen, zeigt unser kostenloser Reifegrad-Check.
Was ist Fehlerkultur?
Fehlerkultur beschreibt, wie eine Organisation mit Fehlern umgeht — ob als Schuldfrage oder als Lernchance. Eine positive Fehlerkultur trennt Person und Problem: Sie sucht die Systemursache statt den Schuldigen und macht Fehler so zur wertvollsten Datenquelle für Verbesserung.
Was ist psychologische Sicherheit?
Psychologische Sicherheit ist die geteilte Überzeugung im Team, dass niemand bloßgestellt oder bestraft wird, wenn er einen Fehler zugibt, eine Frage stellt oder widerspricht. Der Begriff geht auf Amy Edmondson (Harvard) zurück — und ist laut DORA-Forschung der stärkste Einzelfaktor für Team-Performance.
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.
Best Practices:
DevOps-Kultur im
Industrieumfeld aufbauen.
Zehn Praktiken, die wir in Industrial-DevOps-Projekten immer wieder als entscheidend erleben — von der ersten Pilotmannschaft bis zur werksweiten Routine.
Kurz gesagt: Eine tragfähige DevOps-Kultur im Industrial-DevOps-Umfeld ruht auf zehn Best Practices — von psychologischer Sicherheit über Blameless Post-Mortems und gemeinsame DORA-/OEE-Metriken bis zur Automatisierung als Entlastung. Die Tools sind dabei Mittel, nicht Zweck.
- /01
IT und OT an einen Tisch — nicht in zwei Gebäude
Kultur entsteht aus Nähe. Solange Softwareentwickler und Automatisierer in getrennten Welten planen, bleibt jede Pipeline ein Übergabe-Ritual statt gemeinsamer Verantwortung.
Auf dem ShopfloorEin cross-funktionales Team aus SPS-Programmierern, Software- und Plattform-Engineers: gemeinsames Backlog, gemeinsames Daily, ein Definition-of-Done für Steuerungs- und Applikationscode.
- /02
Psychologische Sicherheit vor jedem Tool
Eine Pipeline ist in Tagen gebaut, Vertrauen in Monaten. Wer zuerst Werkzeuge ausrollt und Verhalten ignoriert, automatisiert nur das alte Misstrauen.
Auf dem ShopfloorBevor das erste Jenkinsfile entsteht: Spielregeln für den Umgang mit Fehlern vereinbaren. In der Lern-Zone — hohe Sicherheit, hoher Anspruch — entsteht High Performance, nicht in der Angst-Zone.
- /03
Blameless Post-Mortems zur festen Routine machen
Jeder Anlagenstillstand, jedes fehlgeschlagene Deployment ist eine bezahlte Lernstunde — wenn man sie nutzt, statt einen Schuldigen zu suchen.
Auf dem ShopfloorNach jedem nennenswerten Vorfall ein dokumentiertes Post-Mortem: Timeline, Systemursache, Maßnahme — geteilt im ganzen Werk. „Warum war der Fehler möglich?" statt „Wer war es?".
- /04
Safety ist kein Gegner von Speed, sondern Design-Input
„Move fast and break things" endet an einer Produktionsanlage potenziell mit Personenschaden. Industrial DevOps heißt: schnell liefern und sicher bleiben — kein Entweder-oder.
Auf dem ShopfloorSicherheits- und Compliance-Anforderungen (IEC 62443, Maschinenrichtlinie) als automatisierte Gates in die Pipeline gießen — statt sie als manuelle Bremse ganz am Ende vorzuschalten.
- /05
DORA-Metriken und OEE auf ein Dashboard
IT misst Deployment-Frequenz und MTTR, OT misst Anlagenverfügbarkeit. Erst zusammen ergeben sie ein ehrliches Bild der Leistungsfähigkeit — und beenden Bauchgefühl-Debatten.
Auf dem ShopfloorLead Time, Deployment Frequency, Change Failure Rate und MTTR neben OEE sichtbar machen. Eine gemeinsame Datenbasis für Verbesserung, kein Kontrollinstrument.
- /06
Kaizen und Continuous Improvement als dieselbe Sprache
Maschinenbauer leben Lean seit Jahrzehnten. DevOps verkauft sich im Industrieumfeld am besten nicht als IT-Trend, sondern als Fortsetzung von Kaizen mit anderen Mitteln.
Auf dem ShopfloorRetrospektiven als Shopfloor-Kaizen framen, Wertstromanalyse auf die Deployment-Kette anwenden, kleine reversible Schritte statt großer Big-Bang-Umbauten.
- /07
Tribal Knowledge der OT-Veteranen sichern
Das kritischste Wissen steckt oft im Kopf eines einzigen erfahrenen Automatisierers — und geht mit ihm in Rente. Wissen zu teilen ist Risikomanagement, nicht Nettigkeit.
Auf dem ShopfloorSteuerungscode unter Versionskontrolle, Pair Commissioning von Software- und SPS-Engineer, „Tech Talk Freitag" mit wechselnden IT/OT-Themen (OPC UA, GitOps, PROFINET).
- /08
Führung lebt die Kultur vor — sichtbar
Kultur wird kopiert, nicht angeordnet. Eine Führungskraft, die selbst keine Fehler zugibt, bekommt ein Team, das keine Fehler meldet.
Auf dem ShopfloorManagement nimmt an Retrospektiven teil, benennt eigene Fehlentscheidungen, schirmt Pilotteams von Berichts-Overhead ab und macht messbare Erfolge öffentlich sichtbar.
- /09
Mit einem Pilotteam starten — nicht mit dem Big Bang
Eine werksweite Kultur-Verordnung erzeugt Widerstand. Ein sichtbar erfolgreiches Pilotprojekt erzeugt Sog.
Auf dem ShopfloorEin konkretes, geschütztes IT/OT-Projekt mit klarem Ziel („Deployment-Zeit von 3 Tagen auf 2 Stunden"). Erfolg messen, die Story erzählen, dann skalieren.
- /10
Automatisierung als Entlastung kommunizieren, nicht als Drohung
Wer Angst um seinen Job hat, sabotiert jede Automatisierungsinitiative — leise, aber wirksam. Das Warum entscheidet über Akzeptanz.
Auf dem ShopfloorKlar machen: Automatisierung eliminiert Toil und Routine, nicht Menschen. Frei werdende Zeit fließt in wertschöpfende Arbeit — Engineering statt Copy-Paste-Deployments.
Kein Punkt davon braucht ein neues Tool — alle zehn brauchen Konsequenz. Wo Ihr Team heute steht, ordnet unser kostenloser Reifegrad-Check ein; bei der Umsetzung begleitet unser DevOps-Coaching.
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. Externe DevOps Beratung kann diesen Rahmen moderieren — etwa über begleitetes Führungskräfte-Coaching.
- /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. Wie IT-Unternehmen diesen Kulturwandel erfolgreich gestalten, zeigt unser Anwendungsfall IT-Unternehmen.
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 ist die geteilte Überzeugung im Team, dass niemand bloßgestellt oder bestraft wird, wenn er einen Fehler zugibt, eine Frage stellt oder widerspricht. Der Begriff geht auf die Harvard-Professorin Amy Edmondson zurück und ist laut DORA-Forschung der stärkste Einzelfaktor für Team-Performance. Ohne sie werden Fehler vertuscht und Verbesserungsvorschläge zurückgehalten.
- Q.05
- Was ist eine positive Fehlerkultur?
- Eine positive Fehlerkultur behandelt Fehler als Lernchance statt als Versagen. Sie trennt Person und Problem, verzichtet auf Schuldzuweisungen, analysiert die Systemursache und teilt die Erkenntnisse offen. So wird aus jedem Fehler dokumentiertes organisationales Lernen statt Vertuschung.
- Q.06
- Welche Fehlerkulturen gibt es?
- Grob unterscheidet man eine negative Fehlerkultur, die Energie in die Schuldfrage steckt und Fehler vertuscht, von einer positiven Fehlerkultur, die Fehler offen analysiert und als Lernchance nutzt. Die Westrum-Typologie verfeinert das in drei Stufen: pathologisch (Macht-orientiert), bürokratisch (Regel-orientiert) und generativ (Leistungs-orientiert).
- Q.07
- Was sind die drei Säulen einer Fehlerkultur?
- Eine tragfähige Fehlerkultur ruht auf drei Säulen: psychologische Sicherheit (Fehler dürfen offen angesprochen werden), Blameless-Analyse (Systemursachen statt Schuldige) und Lernen im System (Maßnahmen werden umgesetzt und geteilt). Erst alle drei zusammen verändern das Verhalten dauerhaft.
- Q.08
- 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.09
- 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.10
- 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.11
- 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.
Auf welchen Quellen
dieser Artikel aufbaut.
Die zentralen Konzepte dieses Beitrags — CALMS, psychologische Sicherheit, die Westrum-Typologie und Blameless Post-Mortems — gehen auf etablierte Primärquellen aus Forschung und Praxis zurück:
- /01DORA — DevOps Research and Assessment
Empirische Forschung (Google): High-Trust-Kultur und freier Informationsfluss sagen Software-Delivery- und Organisations-Performance voraus.
https://dora.dev/research/
- /02DORA — Generative Organizational Culture
Die Westrum-Typologie (pathologisch / bürokratisch / generativ) als DevOps-Capability.
https://dora.dev/capabilities/generative-organizational-culture/
- /03Amy C. Edmondson — Psychological Safety
Originaldefinition psychologischer Sicherheit; Buch „The Fearless Organization" (Harvard Business School).
https://amycedmondson.com/psychological-safety/
- /04IT Revolution — DevOps Culture
Ursprung des CALMS-Modells: CAMS von John Willis & Damon Edwards (2010), „L" für Lean ergänzt von Jez Humble.
https://itrevolution.com/articles/devops-culture-part-1/
- /05Google SRE Book — Postmortem Culture
Blameless Post-Mortems: Systemursachen statt Schuldzuweisung (Site Reliability Engineering, Kap. 15).
https://sre.google/sre-book/postmortem-culture/
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