Release-Zyklen von sechs Wochen, Deployments als manueller Kraftakt, Security als nachgelagerter Prüfschritt. In 2 Tagen entsteht Ihr Fahrplan: Reifegrad-Profil, Wertstromkarte, Tool-Entscheidung, Pilot-Plan und KPI-Zielblatt — datiert, mit Namen an jeder Phase.
2 TAGE · MAX. 12 TEILNEHMER · AB 1.890 € · VOR ORT ODER REMOTE
Comquent Consulting Team
Industrial-DevOps-Berater für IT/OT-Umgebungen
Reifegradanalysen, Value-Stream-Mapping, CI/CD für SPS- und Embedded-Software, Quality- und Security-Gates nach IEC 62443 sowie KPI-Frameworks aus DORA- und OT-Kennzahlen. Praxiserfahrung aus Industrieprojekten seit 2006.
Der Workshop Industrial DevOps in 90 Tagen ist ein 2-tägiges Intensiv-Training (16 Stunden, max. 12 Teilnehmer) für IT-, OT- und Engineering-Verantwortliche in Fertigung, Automotive und Maschinenbau. Sie erarbeiten den 90-Tage-Fahrplan für Ihr Unternehmen entlang von vier Phasen mit Quality Gates — Assess (Tag 1–20), Design (Tag 21–40), Implement (Tag 41–75) und Optimize (Tag 76–90). Am Ende stehen vier Arbeitsinstrumente: Reifegrad-Profil, Wertstromkarte, Pilot-Plan und KPI-Zielblatt. Ab 1.890 € netto pro Teilnehmer.
Drei Sätze hören wir in fast jedem Erstgespräch: Release-Zyklen von sechs Wochen. Deployments als manueller Kraftakt. Security als Prüfschritt kurz vor der Freigabe. Die Ursache ist fast immer dieselbe — IT und OT arbeiten in getrennten Welten, mit eigenen Werkzeugen, eigenen Abläufen und eigener Sprache.
Beide Seiten optimieren dabei richtig: Die IT auf Veränderung und Tempo, die OT auf Stabilität und Anlagenverfügbarkeit. Problematisch wird es erst ohne gemeinsame Abläufe. Dann dauern Freigaben Wochen, weil Abstimmung fehlt — und jedes Update wird zum Risiko für die Produktion.
Fast jedes Industrieunternehmen hat schon einmal versucht, das zu ändern. Dass viele dieser Anläufe versanden, liegt selten an der Technik. Es liegt an der Reihenfolge.
Ist Industrial DevOps bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Kein Foliensatz. Kein
Reifegradmodell von der Stange.
Tag 1 arbeitet an Ihrer Ausgangslage: warum Initiativen stecken bleiben, Reifegradanalyse über fünf Dimensionen, Value-Stream-Mapping, KPI-Baseline und die begründete Pilot-Auswahl. Tag 2 führt zum Plan: Tool-Entscheidungsmatrix für OT-Umgebungen, die sechsstufige Pilot-Pipeline, die Dosierung der Quality und Security Gates, der Platz von KI in den 90 Tagen — und am Ende der ausgefüllte Pilot-Plan mit gesetzten Gate-Terminen.
Vier Muster aus abgeschlossenen Projekten: organisatorisch ungeklärte IT/OT-Kluft, zu groß geschnittener Umbau, fehlende Baseline, Security als nachgelagerter Prüfschritt. Ordnen Sie Ihre eigene Ausgangslage ein.
Kultur und Zusammenarbeit, Automatisierung, Continuous Delivery, Monitoring und Feedback, Architektur. Sie bewerten Ihre Organisation entlang des Leitfragenkatalogs und nehmen ein Profil mit Benchmark mit.
Vom Änderungswunsch bis zum Stand auf der Anlage — mit Wartezeiten, Übergaben und manuellen Schritten. In Workshops zeigt sich typischerweise, dass 80 bis 90 % der Durchlaufzeit Wartezeit ist, nicht Arbeitszeit.
Deployment Frequency, Lead Time, Change Failure Rate, Time to Restore — ergänzt um ungeplante Stillstände, Release-Zyklus der Steuerungssoftware und manuelle Schritte pro Release. Wie Sie die Werte automatisiert erheben statt zu schätzen.
Relevanz, Überschaubarkeit, Messbarkeit, Sichtbarkeit, vertretbares Risiko. Sie stellen zwei bis drei Kandidaten gegeneinander und entscheiden am Ende von Tag 1 begründet.
Jenkins, GitLab CI, Azure DevOps, GitHub Actions und ArgoCD entlang neun industrieller Kriterien — Air-Gap, SPS-Builds, Self-Hosted Runner in der OT-Zone, Pipeline as Code. Herstellerunabhängig, mit Begründung fürs Protokoll.
Checkout, Kompilieren, Simulation, Quality Gate, Security Gate, Deployment. Zugeschnitten auf SPS-Umgebungen, übertragbar auf Embedded- und Edge-Software. Inklusive Rückkopplung aus dem Betrieb in den nächsten Commit.
Nicht mehr Gates, sondern bessere: Jedes Gate adressiert ein reales Risiko und gibt schnell Rückmeldung. Wo es zum Engpass wird, umgeht das Team es — und dann wirkt es gar nicht mehr.
Wo Claude Code die Phasen messbar verkürzt: Auswertung der Interviews, erste Pipeline-Entwürfe, SBOM- und Policy-Stages, Management-Reports aus Pipeline-Daten. Und wo sie nichts beiträgt — die Pilot-Entscheidung nimmt Ihnen keine KI ab.
Die Vorlage mit vierzehn Feldern, ausgefüllt für Ihren Piloten: Scope, Team, Zeitplan, Erfolgskriterien, Risiken, Rollback-Strategie, Exit-Kriterien. Am Ende steht ein datierter Plan mit Namen an jeder Phase.
Der Workshop richtet sich an Entscheider und technische Verantwortliche gleichermaßen — IT-Leitung, OT- und Produktionsleitung, Engineering, DevOps- und Compliance-Verantwortliche. Wir empfehlen ausdrücklich, aus beiden Welten je zwei bis drei Personen zu schicken: Die wirksamsten Ergebnisse entstehen dort, wo IT und OT dieselbe Wertstromkarte zeichnen. Technische Vorkenntnisse sind nicht erforderlich.
VoraussetzungenKeine technischen Vorkenntnisse nötig. Hilfreich ist, was Sie ohnehin haben: eine grobe Vorstellung des heutigen Ablaufs vom Änderungswunsch bis zur Anlage, eine Liste der eingesetzten Engineering- und Build-Werkzeuge und — falls vorhanden — Zahlen zu Ausfällen und Release-Häufigkeit. Fehlt das, erarbeiten wir es im Workshop.
Regulierte BranchenVier Regelwerke laufen auf dieselbe Anforderung zu: NIS2, der Cyber Resilience Act, die IEC 62443 und der EU AI Act verlangen, dass Sicherheit und Nachvollziehbarkeit im Entwicklungsprozess entstehen — nicht in einem nachgelagerten Audit. Konkret wird das an einer einzigen Frage im Prüftermin: Wer hat diesen Stand wann freigegeben, und woraus geht das hervor? Wer die Antwort aus Gedächtnis und E-Mail-Verläufen zusammensuchen muss, verliert Tage. Im Workshop schneiden wir das Security Gate so zu, dass der Audit-Trail als Nebenprodukt jedes Releases anfällt.
Zwölf Entscheidungen entscheiden darüber, ob eine Initiative trägt: Standortbestimmung, Zuschnitt des Piloten, Werkzeugentscheidung, Messbarkeit, Sicherheit und Nachweise sowie Verankerung im Team. Ohne Fahrplan fallen sie nebenbei — meist unter Zeitdruck und ohne dass jemand sie später begründen kann. Der Unterschied ist nicht das Werkzeug, sondern die Reihenfolge.
Wissen, wo die Organisation wirklich steht
Bauchgefühl aus dem Führungskreis, jede Abteilung nennt eine andere Ursache
Reifegrad-Profil über fünf Dimensionen, mit Benchmark und drei priorisierten Hebeln
Durchlaufzeit vom Commit bis zur Anlage bestimmen
Geschätzte Werte, die im Nachhinein niemand belegen kann
Wertstromkarte aus einem Workshop-Tag — Wartezeiten, Übergaben und Engpässe sichtbar
Den ersten Anwendungsfall auswählen
Das Projekt mit der lautesten Stimme oder der bequemsten Technologie gewinnt
Fünf Auswahlkriterien: Relevanz, Überschaubarkeit, Messbarkeit, Sichtbarkeit, vertretbares Risiko
Den Umbau so schneiden, dass er endet
Programm über vier Quartale, das die erste Prioritätsänderung nicht überlebt
Ein Pilot mit Scope, Zeitplan, Rollback-Strategie und definiertem Abbruchkriterium
CI/CD-Werkzeug für eine OT-Umgebung wählen
Entscheidung nach Vorliebe, Air-Gap und SPS-Builds fallen erst im Betrieb auf
Entscheidungsmatrix über neun industrielle Kriterien, dokumentiert und begründet
Bestehende Werkzeuglandschaft einbinden
Zweite Toolchain neben der ersten, beide halb gepflegt
Tool-Inventar mit benannten Integrationspunkten und Migrationsreihenfolge
Baseline erheben, bevor etwas verändert wird
Baseline wird am Tag 90 rekonstruiert — und ist genau dann angreifbar
DORA- und OT-Kennzahlen aus Phase 1, automatisiert aus Pipeline und Monitoring
Wirkung gegenüber dem Management belegen
Monatsfolie mit Fortschrittsbalken, die niemand prüfen kann
KPI-Report Baseline gegen Ist plus Wirtschaftlichkeitsrechnung als Entscheidungsvorlage
Security in den Ablauf bekommen
Prüfung kurz vor der Freigabe, jeder Rückläufer kostet ein Wartungsfenster
Security Gate in der Pipeline: SBOM, Signatur und Zonenprüfung bei jedem Build
Nachweise für NIS2, CRA und IEC 62443 erzeugen
Audit-Vorbereitung als Sonderprojekt, Wochen vor dem Termin
Audit-Trail und Stücklisten fallen als Nebenprodukt jedes Releases an
IT und OT auf einen gemeinsamen Ablauf bringen
Zwei Prozesse nebeneinander — der bestehende gewinnt, weil er die Anlage verantwortet
Arbeitsvereinbarungen aus einem gemeinsamen Termin: Ziele, Rollen, Freigabelogik
Wissen im Unternehmen halten
Der externe Partner kennt die Pipeline besser als das eigene Team
Schulung und Pair-Programming als Teil der Umsetzung, nicht als Anhang danach
Zehn Symptome aus abgeschlossenen Projekten, nach Häufigkeit geordnet. Jede Zeile zeigt die Ursache und die Gegenmaßnahme, die wir im Workshop auf Ihre Lage anwenden. Wenn Sie eine dieser Zeilen wiedererkennen, ist der Workshop für Sie gebaut — und Sie sind damit nicht der Sonderfall, sondern der Regelfall.
Die IT baut eine Pipeline, ohne dass die Steuerungsentwicklung ihre Freigabelogik darin wiederfindet. Es entsteht ein zweiter Prozess neben dem bestehenden — und der bestehende gewinnt, weil er die Anlage verantwortet.
Der Fahrplan beginnt mit gemeinsamen Zielen und Arbeitsvereinbarungen, nicht mit einem Werkzeugvergleich. IT und OT definieren im selben Termin Rollen, Freigabelogik und Wartungsfenster.
Der Umbau war zu groß geschnitten: Er sollte die gesamte Werkzeuglandschaft eines Werks ablösen und band Kapazität, bevor er den ersten Nutzen zeigte. Ein Anlauf, ein Kundenprojekt, ein Personalwechsel — und ein halb fertiger Zustand bleibt zurück.
Ein abgegrenzter Pilot mit definiertem Abbruchkriterium ist belastbarer als ein Programm ohne Ausstieg. Scope, Exit-Kriterien und Rollback stehen im Pilot-Plan, bevor die erste Zeile entsteht.
Durchlaufzeiten, Fehlerraten und Ausfallzeiten wurden nicht gemessen, bevor etwas geändert wurde. Baseline-Werte werden nachträglich rekonstruiert und sind dann angreifbar — genau dann, wenn Budget für die Skalierung beantragt wird.
Die KPI-Baseline entsteht in Phase 1, automatisiert aus Pipeline- und Monitoring-Systemen. Am Tag 90 steht ein Vergleich Baseline gegen Ist, den auch ein skeptischer Controller nachrechnen kann.
Solange Sicherheitsprüfungen erst vor der Freigabe stattfinden, treffen sie auf fertige Stände. Jeder Rückläufer kostet ein Wartungsfenster, und der Freigabetermin wird unplanbar.
Dieselben Prüfungen wandern in die Pipeline: statische Analyse bei jedem Commit, Abhängigkeits- und Artefakt-Scans, automatisch erzeugte SBOM. Die Nachweise entstehen dort, wo die Änderung entsteht.
Gates werden nach Vollständigkeit gesetzt statt nach Risiko. Die Pipeline wird zum Engpass, Rückmeldungen kommen zu spät, und irgendwann führt jemand den Build wieder lokal aus.
Dosierung statt Menge: Jedes Gate muss ein reales Risiko adressieren und schnell Rückmeldung geben. Im Workshop schneiden Sie die Gate-Kette für Ihren Piloten konkret zu.
Die Auswahl folgte der bequemsten Technologie oder der lautesten Stimme im Raum. Der Pilot funktioniert danach technisch — überzeugt aber niemanden, weil er kein Problem löst, das jemand hatte.
Fünf Auswahlkriterien entscheiden: Relevanz, Überschaubarkeit, Messbarkeit, Sichtbarkeit und vertretbares Risiko. Sie stellen im Workshop mehrere Kandidaten gegeneinander und dokumentieren die Wahl.
In der Produktion ist der Rückweg keine akademische Übung. Wenn er zum ersten Mal im Ernstfall gegangen wird, ist das Vertrauen in die Automatisierung nach einem Versuch aufgebraucht.
Der Rückweg wird geprobt, bevor der erste automatisierte Stand produktiv geht. Rollback-Strategie und maximal zulässige Wiederherstellungszeit sind Pflichtfelder im Pilot-Plan.
Engineering-Umgebungen wie TIA Portal oder CODESYS gelten als nicht automatisierbar, weil die Bedienung über die Oberfläche gedacht wird. Tatsächlich fehlt meist nur der Einstieg über die Programmierschnittstellen.
Die Pilot-Pipeline nutzt die Openness-API beziehungsweise den CODESYS-Automation-Server, testet gegen Simulation und ergänzt Hardware-in-the-Loop, wo Prüfstände verfügbar sind.
Befähigung wird als Abschlussveranstaltung geplant. Bis dahin kennt der externe Partner die Pipeline besser als das eigene Team, und jede Änderung braucht wieder einen Auftrag.
Hands-on-Workshops und Pair-Programming laufen während der Umsetzung mit, nicht danach. Befähigung statt Abhängigkeit ist eines der drei Prinzipien über alle vier Phasen.
Argumentiert wird mit Deployment-Frequenz und Lead Time — Kennzahlen, die im Engineering überzeugen und in der Geschäftsführung nicht ankommen.
Die Kennzahlen werden übersetzt: eingesparte Wartungsfenster, weniger ungeplante Stillstände, entfallender Aufwand für manuelle Nachweise. Die Entscheidungsvorlage am Tag 90 rechnet in Euro.
Quelle der Auswahl: Comquent-Projekte in Fertigung, Automotive und Maschinenbau 2024–2026, gewichtet nach Häufigkeit und danach, wie teuer die Korrektur später wurde. Jede Zeile entspricht einem konkreten Arbeitsblock im Workshop.
Ist ein 90-Tage-Fahrplan bei Ihnen der richtige nächste Schritt?
Ein Fahrplan hilft, wenn die Richtung fehlt — nicht, wenn eine konkrete Aufgabe im Weg steht. Zwei Klicks ordnen ein, ob der Workshop bei Ihrem Ausgangspunkt trägt oder ob davor etwas anderes gehört.
Was treibt das Thema bei Ihnen gerade?
Jede Phase hat ein klar definiertes Ergebnis, das als Quality Gate für die nächste dient. Wird ein Gate nicht erreicht, wird nachgesteuert, bevor weiter investiert wird — dieses Prinzip schützt Budget und Vertrauen gleichermaßen.
| Phase | Zeitraum | Inhalt | Quality Gate |
|---|---|---|---|
1 Assess | Tag 1–20 | Reifegradanalyse, Value-Stream-Mapping, Stakeholder-Interviews, Tool-Landscape-Assessment | Reifegrad-Report mit Benchmark und priorisierten Hebeln |
2 Design | Tag 21–40 | Roadmap, Tool-Entscheidung, Pilot-Plan, KPI-Baseline, Team-Alignment | Freigegebener Pilot-Plan inklusive Erfolgskriterien |
3 Implement | Tag 41–75 | Pilot-Pipeline, Versionierung, Quality Gates, Security-Integration, Schulungen | Lauffähige Pipeline, erste automatisierte Deployments |
4 Optimize | Tag 76–90 | KPI-Monitoring, Feedback-Schleifen, Retrospektive, Skalierungs-Roadmap | KPI-Report Baseline gegen Ist, Entscheidungsvorlage Rollout |
Kein Deployment geht ohne bestandene Quality Gates und ohne geprüften Rollback-Pfad live. Diese Regel steht vor jedem Tempo-Ziel — und sie ist der Grund, warum die OT den Fahrplan mitträgt.
Die KPI-Baseline wird in Phase 1 erhoben, nicht am Ende rekonstruiert. Wer erst am Tag 85 nach Vergleichswerten sucht, hat am Tag 90 eine Behauptung statt eines Belegs.
Schulungen und Pair-Programming sind Bestandteil der Implementierung, nicht optionales Beiwerk. Nach 90 Tagen soll Ihr Team die Pipeline weiterentwickeln können, ohne einen Auftrag zu schreiben.
Warum ausgerechnet 90 Tage? Lang genug für einen vollständigen Zyklus aus Analyse, Design, Umsetzung und Messung — kurz genug, um Fokus zu erzwingen. Die vollständige Transformation einer Organisation dauert typischerweise 12 bis 18 Monate. Nur sollte niemand monatelang auf den ersten Beleg warten, dass der Ansatz trägt. Mehr zum Modell steht im Beitrag Industrial DevOps: der Leitfaden.
In Phase 3 entsteht eine Kette, die jede Änderung am Steuerungscode vom Repository bis in die Anlage führt. Die Stufen sind für SPS-Umgebungen zugeschnitten; das Muster gilt genauso für Embedded- und Edge-Software. Im Workshop bauen wir sie an einem Beispielprojekt auf — und Sie übertragen sie auf Ihren Piloten.
Steuerungscode aus Git, identische Umgebung je Lauf
Git, IaC-Agenten
Projekt bauen und exportieren über die Engineering-API
TIA Openness, CODESYS
Tests gegen Simulation, virtuelle Inbetriebnahme, HiL wo verfügbar
PLCSIM Advanced, HiL
IEC 61131-3-Regeln, Coverage, statische Analyse, Review-Status
Statische Analyse
CVE-Scan, SBOM, signierte Artefakte, Prüfung gegen das Zonenprofil
SCA, OPA, Sigstore
Freigabe im Wartungsfenster, geprobter Rollback-Pfad
Artefakt-Registry
Die Kette endet nicht am Deployment: Betriebsdaten und Vorfälle fließen zurück in den nächsten Commit. Ohne diese Rückkopplung bleibt eine Pipeline eine Einbahnstraße.
Beispielausgaben aus der Workshop-Umgebung. Die Werte der Baseline stammen aus einem anonymisierten Kundenprojekt der Fertigungsindustrie.
KI nimmt Ihnen die Pilot-Entscheidung nicht ab — und die Arbeitsvereinbarung zwischen IT und OT schon gar nicht. Bei der Auswertung, beim ersten Pipeline-Entwurf und beim Reporting spart sie dagegen ganze Tage. Zwei Prompts je Phase, alle im Workshop erprobt.
Diese acht sind der Kern unseres Cheat-Sheets, das jeder Teilnehmer als Referenz mitnimmt.
claude "Werte diese acht Interview-Protokolle aus IT, OT und Produktion aus: gruppiere Schmerzpunkte nach Häufigkeit, markiere Zielkonflikte zwischen den Rollen und benenne die drei Themen, die alle Gruppen nennen"
claude "Lies diesen Jira-Export und berechne je Statusübergang die Median-Liegezeit; stelle Bearbeitungszeit gegen Wartezeit und markiere die drei größten Wartepositionen"
claude "Bewerte Jenkins, GitLab CI und Azure DevOps für diese Ausgangslage: air-gapped OT-Zone, TIA-Portal-Builds, bestehendes Active Directory, vier Entwickler — und begründe jede Abweichung von der allgemeinen Matrix"
claude "Erzeuge aus dieser Pilot-Beschreibung einen Steckbrief nach unserer Vorlage: Problemstellung, Ziel und Hypothese, Scope in/out, Erfolgskriterien mit Baseline und Zielwert, fünf Risiken mit Gegenmaßnahme, Rollback-Strategie, Exit-Kriterien"
claude "Schreibe eine Jenkinsfile-Stage, die ein TIA-Portal-Projekt über die Openness-API kompiliert, das Ergebnis als Artefakt ablegt und bei Kompilierfehlern den zuständigen Kanal informiert"
claude "Ergänze die Pipeline um ein Security Gate: CycloneDX-SBOM erzeugen, Abhängigkeiten gegen die CVE-Datenbank prüfen, Artefakt signieren und den Build bei kritischen Findings anhalten"
claude "Berechne aus diesen Build- und Deployment-Logs die vier DORA-Metriken je Woche seit Projektbeginn und stelle sie der Baseline aus Phase 1 gegenüber"
claude "Fasse KPI-Report und Retrospektive zu einer Entscheidungsvorlage zusammen: erreichte Zielwerte, offene Punkte, Aufwand für die nächsten zwei Teams, Empfehlung mit Alternative"
Industrial DevOps in 90 Tagen — das vollständige Papier mit Phasenmodell, Tool-Entscheidungsmatrix, Pilot-Plan-Vorlage und KPI-Framework. Grundlage dieses Workshops, kostenlos gegen Kontaktdaten.
Die Kurzfassung des Fahrplans — erst messen, dann einen abgegrenzten Piloten aufsetzen, erst Stabilität, dann Tempo. Und Security von der ersten Stufe an in der Pipeline statt in einem nachgelagerten Audit. Zeitrahmen: 90 Tage bis zum Nachweis.
Reifegradanalyse über fünf Dimensionen, Interviews mit IT, OT, Produktion und Security, dazu ein Value-Stream-Mapping des heutigen Ablaufs. Parallel entsteht die KPI-Baseline aus Pipeline- und Monitoring-Daten. Ohne diesen Schritt lässt sich am Tag 90 nichts belegen.
Fünf Kriterien entscheiden: Relevanz, Überschaubarkeit, Messbarkeit, Sichtbarkeit und vertretbares Risiko. Ein abgegrenztes System, ein Team, eine Linie — kein unternehmensweiter Scope. Das Ergebnis ist ein Pilot-Steckbrief mit Exit-Kriterien.
Air-Gap-Fähigkeit, Eignung für SPS-Builds, Self-Hosted Runner in der OT-Zone, Pipeline as Code und Einbindung der bestehenden Landschaft. Die Entscheidungsmatrix ersetzt keine Evaluierung im eigenen Kontext, sie strukturiert sie — und liefert die Begründung fürs Protokoll.
Sechs Stufen von Checkout bis Deployment: Versionierung der Assets, Build-Automatisierung, Tests gegen Simulation, Quality Gate, Security Gate mit SBOM und Signatur, Freigabe im Wartungsfenster mit geprobtem Rollback. Umsetzung in Zwei-Wochen-Inkrementen, Schulung läuft mit.
Vergleich Baseline gegen Ist, Wirtschaftlichkeitsrechnung, Retrospektive entlang dreier Fragen: Was hat funktioniert, was hat gebremst, was machen wir beim Rollout anders. Die Antworten fließen in wiederverwendbare Pipeline-Templates, damit das nächste Team nicht bei null anfängt.
Kurzform: Jenkins bietet die größte Flexibilität und eignet sich besonders dort, wo bestehende Infrastruktur eingebunden und SPS-Builds automatisiert werden müssen — etwa das TIA Portal über die Openness-API. GitLab CI punktet als All-in-One-Plattform, Azure DevOps in Microsoft-geprägten Umgebungen, GitHub Actions durch die niedrige Einstiegshürde. ArgoCD ist das Mittel der Wahl für GitOps-Deployments auf Kubernetes, etwa auf Edge-Clustern. Entscheidend ist, was zum Kontext passt — nicht, was am meisten kann.
| Kriterium | Jenkins | GitLab CI | Azure DevOps | GitHub Actions | ArgoCD |
|---|---|---|---|---|---|
| Flexibilität und Erweiterbarkeit | ++ | + | + | + | o |
| On-Premise, Air-Gapped-OT | ++ | ++ | + | o | ++ |
| Eignung für SPS/PLC-Builds | ++ | + | + | o | o |
| All-in-One (Repo, CI, Registry) | o | ++ | ++ | + | o |
| Microsoft-Ökosystem | o | o | ++ | + | o |
| Kubernetes und GitOps | o | + | + | + | ++ |
| Lernkurve und Wartungsaufwand | o | + | + | ++ | + |
| Pipeline as Code | ++ | ++ | ++ | ++ | ++ |
| Self-Hosted Runner in der OT-Zone | ++ | ++ | + | + | ++ |
Bewertung: ++ sehr gut geeignet, + gut geeignet, o bedingt geeignet · Stand August 2026. Die Matrix ersetzt keine Evaluierung im eigenen Kontext, sie strukturiert sie — im Workshop wenden Sie die neun Kriterien auf Ihre Ausgangslage an und dokumentieren die Entscheidung mitsamt Begründung.
SPS- oder Embedded-Builds automatisiert werden müssen, die OT-Zone air-gapped ist und bestehende Infrastruktur eingebunden werden soll. Der Preis dafür ist Wartungsaufwand — Plugin-Pflege und Härtung gehören eingeplant.
Jenkins Administration & KIRepository, Pipeline und Registry aus einer Hand kommen sollen oder die Organisation ohnehin Microsoft-geprägt ist. Für reine SPS-Builds bleibt der Weg über eigene Runner in der OT-Zone.
Werkzeuge im VergleichEdge-Cluster oder Kubernetes-Workloads im Spiel sind und der Sollzustand aus Git kommen soll. ArgoCD ersetzt dabei keine CI — es übernimmt die Auslieferung nach dem Build.
ArgoCD & GitOps mit KIDas Arbeitsergebnis des zweiten Tages ist kein Protokoll, sondern ein freigabefähiger Pilot-Plan. Er wird in Phase 2 ausgefüllt, vom Management freigegeben und dient in Phase 3 und 4 als verbindliche Referenz.
Empfehlung aus der Praxis: maximal zwei Seiten. Ein längerer Pilot-Plan hat meist einen zu großen Scope. Und zwei Felder werden regelmäßig unterschätzt — Rollback-Strategie und Exit-Kriterien. Genau sie sind gegenüber OT- und Produktionsverantwortlichen die wirksamsten Vertrauensanker: Wer von Anfang an definiert, wie kontrolliert zurückgerollt wird, nimmt der Initiative das Risiko-Stigma.
industrial-devops-90-tage/ ├── 01-assess/ │ ├── reifegrad-profil.md │ ├── wertstromkarte.pdf │ ├── interview-synthese.md │ └── tool-inventar.md ├── 02-design/ │ ├── pilot-plan.md │ ├── tool-entscheidung.md │ ├── kpi-zielblatt.md │ └── arbeitsvereinbarung-it-ot.md ├── 03-implement/ │ ├── pipeline/ │ │ ├── Jenkinsfile │ │ ├── quality-gate.groovy │ │ └── security-gate.groovy │ ├── rollback-runbook.md │ └── schulungsplan.md ├── 04-optimize/ │ ├── kpi-report-template.md │ ├── retrospektive-leitfaden.md │ └── entscheidungsvorlage-rollout.md ├── prompts/ │ └── cheat-sheet-90-tage.md ├── CLAUDE.md └── README.md
Alle Vorlagen als Markdown im Git-Repository, nicht als PDF-Sammlung — damit der Fahrplan versioniert wird wie alles andere auch. Die CLAUDE.md enthält Ihren Kontext für die acht Prompts aus Abschnitt 08.
Sie verlassen den Workshop nicht mit einem Foliensatz, sondern mit vier ausgefüllten Arbeitsinstrumenten für Ihr Unternehmen: einem Reifegrad-Profil über fünf Dimensionen, einer Wertstromkarte mit den tatsächlichen Wartezeiten, einem freigabefähigen Pilot-Plan und einem KPI-Zielblatt mit Baseline und Zielwert für Tag 90. Dazu der Moment am zweiten Nachmittag, in dem IT und OT zum ersten Mal auf dieselbe Karte zeigen und dieselbe Engstelle meinen.
Ihre Organisation bewertet über fünf Dimensionen, mit Benchmark und den drei Hebeln, die bei Ihnen zuerst etwas bewegen — die Grundlage für jedes weitere Gespräch mit der Geschäftsführung.
Der Weg vom Änderungswunsch bis zur Anlage, mit Wartezeiten und Übergaben. Sichtbar wird meist, dass die Arbeitszeit selten das Problem ist — die Liegezeit dazwischen ist es.
Vierzehn Felder, ausgefüllt und freigabefähig: Scope, Team, Erfolgskriterien, Risiken, Rollback-Strategie, Exit-Kriterien. Ein längerer Pilot-Plan hat meist einen zu großen Scope.
Baseline und Zielwert je Kennzahl, dazu die Messverfahren. Damit lässt sich am Tag 90 belegen, was gewirkt hat — statt es zu behaupten.
Das Phasenmodell stammt nicht aus einem Beratungshandbuch. Es ist die Ableitung aus Projekten, die wir zu Ende gebracht haben — mit allen Stellen, an denen wir selbst zu groß geschnitten oder zu spät gemessen haben.
Deshalb steht in diesem Workshop auch, wann ein Pilot abgebrochen gehört. Das steht selten in Foliensätzen.
Gegründet 2006 in Puchheim bei München. Wir kommen aus der Software-Qualitätssicherung und sind mit unseren Kunden in die Automatisierung hineingewachsen — von der Bürosoftware bis zur Edge-Steuerung.
Automotive, SPS/PLC: Release-Zyklus von sechs Wochen auf drei Tage, Deployments im geplanten Wartungsfenster mit aktivem Rollback-Pfad. Fertigungsindustrie, SCADA/DCS: ungeplante Ausfälle um 85 % zurückgegangen, jede Änderung nachvollziehbar und rückrollbar. Beide Projekte folgten der Phasenlogik, die Sie im Workshop erarbeiten.
Wir verkaufen keine Lizenzen und haben keine Partnerschaft zu verteidigen. In der Entscheidungsmatrix steht deshalb auch, wo Jenkins der falsche Weg ist — und wo eine bestehende Landschaft besser bleibt, als sie zu ersetzen.
Schulungssprache Deutsch, Unterlagen auf Deutsch, Rechnung aus Deutschland. Geeignet auch für regulierte Branchen und öffentliche Auftraggeber. Die Trainer sitzen am Montag wieder im Kundenprojekt.
Der Fahrplan legt fest, was gebaut wird. Wenn die Entscheidung auf Jenkins fällt, baut dieser Workshop die Plattform darunter — Konfiguration als Code, Härtung, Monitoring.
Mit Ihren eigenen Zahlen, Ihrem Wertstrom und Ihren Normen — ab 4 Teilnehmern. Für diesen Workshop das empfohlene Format: Der Fahrplan wird konkreter, wenn IT und OT gemeinsam im Raum sitzen.
Erstgespräch · 30 Minuten · unverbindlich
Die Fragen, die Entscheider vor der Anmeldung am häufigsten stellen — kompakt beantwortet: Was Industrial DevOps von klassischem DevOps unterscheidet, welche Kennzahlen wirklich tragen, was die vier Regelwerke konkret verlangen und was sich in 90 Tagen wirtschaftlich rechnet.
Drei Punkte. Erstens werden zusätzlich zu reiner Software auch SPS-Steuerungen, SCADA-Systeme, Prozessleitsysteme und Embedded-Software einbezogen. Zweitens erfordern Safety- und Echtzeitanforderungen angepasste Test- und Release-Strategien: Blue-Green-Deployments und Canary-Releases werden auf industrielle Rahmenbedingungen wie geplante Wartungsfenster zugeschnitten. Drittens ist der Kulturwandel anspruchsvoller, weil SPS-Programmierung und Software-Entwicklung unterschiedliche Berufsbilder mit eigener Fehlerkultur sind.
Mehr dazu auf der Leistungsseite Industrial DevOps und im Glossar.
Die vier DORA-Metriken plus fünf OT-Kennzahlen. DORA — Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore — ist der wissenschaftlich validierte Standard für Delivery-Performance. In Produktionsumgebungen reichen sie allein nicht: Ungeplante Anlagenstillstände, der Release-Zyklus der Steuerungssoftware, manuelle Schritte pro Release, Testabdeckung im Steuerungscode und die Zeit bis zur Erkennung einer Schwachstelle gehören dazu.
Wichtig ist die Reihenfolge der Optimierung: erst Stabilität (Change Failure Rate, Time to Restore), dann Geschwindigkeit (Deployment Frequency, Lead Time). In der Produktion ist Verlässlichkeit die Voraussetzung für Tempo, nicht umgekehrt. Alle Werte werden automatisiert aus Pipeline- und Monitoring-Systemen erhoben, nicht von Hand gepflegt.
Typische OT-Baseline gegen Zielwert am Tag 90 · Quelle: DORA-Forschung (Accelerate / State of DevOps) plus abgeschlossene Comquent-Projekte · Ausgangslagen unterscheiden sich je Projekt
Annahme: eine Fertigungslinie mit 2.500 € Stillstandskosten pro Stunde, sechs software-bedingte ungeplante Ausfälle pro Jahr zu je vier Stunden. Konservativ gerechnet — bei getakteten Linien mit Lieferverpflichtung liegt der Stundensatz deutlich höher, und Anlaufkosten nach dem Wiederhochfahren sind nicht enthalten.
6 Ausfälle × 4 h × 2.500 € pro Jahr und Linie.
Bei 85 % weniger ungeplanten Ausfällen (Praxisbeispiel SCADA/DCS) — ≈ 51.000 € pro Jahr und Linie.
Quellenlage: Die Reduktion um 85 % stammt aus einem abgeschlossenen Comquent-Projekt in der Fertigungsindustrie (Git-Versionierung der OT-Landschaft plus Infrastructure as Code). Weitere gemessene Effekte in denselben Projekten: Build-Zeit −70 %, Change Failure Rate −75 %, manuelle Schritte pro Release −100 %, Deployment-Frequenz rund verzehnfacht. Marktseitige Einordnung: Mordor Intelligence (DevOps-Marktvolumen 2026: 19,57 Mrd. USD, CAGR 21,33 %) und die DORA-Forschung. Ihre Ausgangslage bestimmt das Ergebnis — der Reifegrad-Check gibt die erste Einordnung.
Stillstand ist nur einer von drei Kostenblöcken. Wie sich Stillstand, manuelle Rollouts und spät entdeckte Fehler zu einer Jahresbilanz addieren, zeigt der Beitrag Kosten senken mit Industrial DevOps: drei Rechnungen. Für die eigenen Zahlen: ROI-Rechner.
Vier Adressatenkreise, eine gemeinsame Anforderung: Sicherheit und Nachvollziehbarkeit müssen im Entwicklungsprozess entstehen, nicht in einem nachgelagerten Audit. NIS2 verlangt Risikomanagement, Incident-Response, Supply-Chain-Security und die Meldung erheblicher Vorfälle binnen 24 Stunden; die Geschäftsleitung haftet persönlich. Der Cyber Resilience Act folgt einem Stufenplan: seit 11.06.2026 sind Konformitätsbewertungsstellen benannt, ab 11.09.2026 gilt die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen an die ENISA, ab 11.12.2027 ist die Verordnung vollständig anwendbar — verlangt werden SBOM, Schwachstellenmanagement über den Lebenszyklus und Security-Updates über mindestens fünf Jahre.
Die IEC 62443 ist in der Pipeline als automatisiertes Quality Gate umsetzbar: Jedes Deployment wird gegen die Anforderungen seiner Zielzone geprüft. Beim EU AI Act gelten die Pflichten für Modelle mit allgemeinem Verwendungszweck seit dem 02.08.2026; die Hochrisiko-Pflichten nach Anhang III wurden durch die Verordnung (EU) 2026/1744 auf den 02.12.2027 verschoben, für regulierte Produkte nach Anhang I auf den 02.08.2028. Pipeline-relevant sind dort Modellversionierung, Herkunftsnachweis der Trainingsdaten, Audit-Trail und dokumentierte menschliche Aufsicht.
Die gute Nachricht: Eine sauber aufgesetzte Pipeline erfüllt einen großen Teil dieser Anforderungen als Nebenprodukt. Automatisch erzeugte Stücklisten, signierte Artefakte mit Herkunftsnachweis, Compliance-Regeln als Code und lückenlose Audit-Trails machen eine Organisation dauerhaft prüfbereit. Details auf der Leistungsseite DevSecOps & Compliance.
Fünf Kriterien. Relevanz: Der Pilot adressiert einen echten Schmerzpunkt, etwa langsame SPS-Release-Zyklen — kein Randthema. Überschaubarkeit: ein abgegrenztes System, ein Team, eine Anlage oder Linie. Messbarkeit: Baseline-Werte existieren oder lassen sich in Phase 1 erheben. Sichtbarkeit: Das Ergebnis ist für Management und Nachbarteams erkennbar — der Pilot soll überzeugen, nicht nur funktionieren. Vertretbares Risiko: Ein Rollback ist jederzeit möglich, die Produktionssicherheit zu keinem Zeitpunkt gefährdet.
Im Workshop stellen Sie zwei bis drei Kandidaten aus Ihrem Haus gegeneinander und entscheiden am Ende von Tag 1 begründet — inklusive der Kandidaten, die durchfallen. Auch das ist ein Ergebnis.
Auf Basis der Ergebnisse entsteht die Entscheidungsvorlage: Welche Teams und Systeme folgen als Nächstes, welche Investitionen in Plattform, Schulung und Personal sind nötig? Der vollständige Rollout dauert je nach Komplexität 6 bis 12 Monate. Bewährte Muster sind Communities of Practice, ein zentrales Plattform-Team mit Self-Service-Angeboten und die schrittweise Einführung von SRE-Praktiken mit Service Level Objectives und Error Budgets.
Für den Betrieb danach gibt es zwei Modelle: Das Unternehmen übernimmt Pipeline und Plattform vollständig selbst — oder der laufende Betrieb inklusive Pflege der Security-Gates wird ausgelagert. Beides ist legitim; die Entscheidung hängt an der Kapazität, nicht am Anspruch. Mehr dazu unter Automation as a Service.
Welches Format passt bei Industrial DevOps besser zu Ihrem Team?
Den Workshop gibt es als offenen Termin und als Inhouse-Format im eigenen Team. Sagen Sie uns mit einem Klick, was für Sie näher liegt — den passenden Weg zeigen wir direkt danach.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
