DevOps vs. Platform Engineering in der Industrie.Was davon bis zur SPS trägt.
In der IT ist Platform Engineering angekommen: Im DORA-Bericht 2025 nutzen 90 Prozent der befragten Organisationen eine interne Entwicklerplattform. In der Automatisierung sieht es anders aus. Wir trennen die Begriffe, zeigen, welche Bausteine es für SPS-Projekte heute gibt, und wo das Modell an Safety, Echtzeit und alten Anlagen endet.
AIDevOps ist die Arbeitsweise, die Entwicklung und Betrieb zusammenbringt. Platform Engineering ist ein Team, das diese Arbeitsweise als interne Plattform mit Self-Service und Golden Paths an viele Teams ausliefert. Auf die SPS-Entwicklung lässt sich das übertragen, mit einer Einschränkung: Ein herstellerübergreifendes Entwicklerportal für die OT gibt es bis heute nicht. Was trägt, sind Git für Steuerungscode, Tests in der Simulation und zentrales Lifecycle-Management über viele Controller.
Ist Platform Engineering 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.
Was ist der Unterschied zwischen DevOps und Platform Engineering?
DevOps beschreibt, wie Entwicklung und Betrieb zusammenarbeiten: gemeinsame Verantwortung, automatisierte Auslieferung, schnelle Rückmeldung aus dem Betrieb. Platform Engineering ist die organisatorische Antwort auf eine Nebenwirkung davon. Wenn jedes Team Pipelines, Umgebungen und Sicherheitsregeln selbst bauen muss, wächst die Arbeit, die neben der eigentlichen Aufgabe herläuft. Ein Plattform-Team nimmt sie ab und liefert eine interne Plattform, die die Teams selbst bedienen. Platform Engineering ersetzt DevOps also nicht. Es macht die Arbeitsweise für viele Teams wiederholbar.
Wie verbreitet das inzwischen ist, zeigt der DORA-Bericht 2025: 90 Prozent der befragten Organisationen nutzen eine interne Entwicklerplattform, 76 Prozent haben dafür ein eigenes Plattform-Team. Der interessantere Befund steht daneben. Ob KI-Werkzeuge einer Organisation etwas bringen, hängt an der Qualität dieser Plattform. Ist sie gut, wirkt KI deutlich positiv auf die Leistung der Organisation. Ist sie schwach, bleibt der Effekt vernachlässigbar.
Für Werke, die gerade über KI in der SPS-Programmierung nachdenken, ist das der eigentliche Grund, sich mit Platform Engineering zu befassen. Ein KI-Assistent, der Steuerungscode schreibt, hilft wenig, wenn niemand prüfen kann, was er geändert hat, und kein Test läuft, bevor der Code auf die Anlage geht.
Wo steht die DevOps-Plattform dazwischen?
In Ausschreibungen wird ein dritter Begriff gern mit beiden vermischt: die DevOps-Plattform. Gemeint ist ein gekauftes Produkt wie GitLab oder Azure DevOps, das Repository, CI/CD und Registry in einem Werkzeug bündelt. So eine Plattform ist eine Voraussetzung für Platform Engineering, aber noch keine interne Entwicklerplattform. Dazu wird sie erst, wenn ein Team darauf Golden Paths für die eigenen Projekte baut und sie als Produkt pflegt. Welches Werkzeug in welcher Umgebung trägt, vergleicht der Artikel Jenkins vs GitLab vs Azure DevOps.
Lässt sich Platform Engineering auf SPS und OT übertragen?
Ja, in Teilen. Self-Service, Golden Paths und die Plattform als Produkt passen auch auf Steuerungscode. Es fehlt aber die Schicht, die in der IT alles zusammenhält: ein herstellerübergreifendes Entwicklerportal wie Backstage. Eine Plattform für die OT entsteht deshalb heute aus einzelnen Bausteinen, und drei davon sind inzwischen reif genug.
Git direkt aus dem Engineering-System
Seit TIA Portal V21 (November 2025) exportiert Siemens Bausteine in ein Textformat, das Git Zeile für Zeile vergleichen kann. Vorher lief das über das Version Control Interface und Openness. CODESYS hat mit V3.5 SP22 im März 2026 ein dateibasiertes Projektformat als Vorschau nachgelegt, das ausdrücklich für Versionsverwaltung gebaut ist; die Anbindung läuft über das Add-on CODESYS Git. TwinCAT 3 legt Bausteine ohnehin als einzelne Dateien ab und bringt eine Git-Anbindung in der Entwicklungsumgebung mit.
TIA Portal mit Git versionierenTests in der Simulation statt am Prüfstand
Über die API von PLCSIM Advanced startet eine Pipeline eine virtuelle S7-1500, lädt das Programm und arbeitet Testfälle ab. CODESYS bringt eine Simulation im Entwicklungssystem mit. Hardware-in-the-Loop bleibt für Timing und gerätespezifisches Verhalten, aber nicht mehr für jeden Test.
Glossar: Hardware-in-the-LoopLifecycle über viele Controller
Der CODESYS Automation Server verteilt Projekte an viele Steuerungen, versioniert jeden Stand automatisch und erlaubt Remote-Debugging, herstellerübergreifend für alle Geräte mit CODESYS-Runtime. Bei den anderen Herstellern übernehmen das deren Edge- und Geräteverwaltungen, jeweils für die eigene Hardware.
Versionsverwaltung in der Industrial IT
AIGebaut wird daraus meist Projekt für Projekt. Falls Ihre Pipelines so entstanden sind, liegen bei Ihnen vermutlich mehrere Build-Skripte für dieselbe Steuerungsfamilie nebeneinander, jedes aus einem anderen Projekt und jedes mit eigenen Annahmen über Pfade, Lizenzen und Versionen. Aus diesen Skripten eine Plattform zu machen, ist der Schritt, um den es in diesem Artikel geht.
Was leisten die Plattformen der Hersteller?
Mehrere Hersteller verkaufen inzwischen „Plattformen“. Die meisten sind App-Marktplätze für das Edge mit einer Geräteverwaltung dahinter. Das ist nützlich, aber etwas anderes als eine interne Entwicklerplattform für das SPS-Engineering:
Für Anlagen, die 20 Jahre und länger laufen, zählt dabei weniger der App-Store als die Frage, ob eine Plattform auch alte Steuerungen und alte Projektstände mitverwalten kann. Das leisten heute vor allem die herstellerneutralen Ansätze, und auch die nur für die Steuerungen, die sie unterstützen.
Was braucht die OT zuerst, internes Entwicklerportal oder interne Entwicklerplattform?
Zuerst die interne Entwicklerplattform (Internal Developer Platform, IDP), danach das Portal. Die Plattform ist der Unterbau aus Pipelines, Umgebungen, Bibliotheken und Richtlinien, der hinter jedem Knopf im Portal tatsächlich läuft. Das interne Entwicklerportal ist die Oberfläche, über die Entwickler Projekte anlegen, Umgebungen anfordern und Deployments starten. Platform Engineering ist die Disziplin, die beides als Produkt betreibt.
In der IT ist diese Dreiteilung Alltag. In der Automatisierung fehlt bisher beides. Für SPS-Projekte gibt es kein herstellerübergreifendes Portal, und was im Hintergrund automatisiert, ist meist projektweise gewachsen. Wer in der OT über ein Entwicklerportal nachdenkt, sollte deshalb zuerst prüfen, ob es überhaupt etwas gibt, das ein Knopf im Portal auslösen könnte: eine Pipeline, die Steuerungscode kompiliert, in der Simulation testet und den Download anstößt. Ohne diesen Unterbau bleibt das Portal ein Katalog, in dem nichts passiert.
AIWie sich die drei Schichten auf der IT-Seite abgrenzen und in welcher Reihenfolge man sie einführt, steht im Grundlagenartikel Internes Entwicklerportal vs. interne Entwicklerplattform. Die Kurzdefinition steht im Glossar unter Internal Developer Platform (IDP). Ob Backstage, Port oder Cortex zu einem IT-Team passt, vergleicht der Anwendungsfall Platform Engineering für IT-Unternehmen.
Wer baut heute schon Plattformen für die OT?
Am weitesten ist eine Forschungseinrichtung: CERN testet automatisch erzeugten SPS-Code in einer Pipeline. Aus der Industrie kommen ein herstellerneutraler Anbieter und zwei Lehrstücke, die zeigen, woran Plattformen scheitern und wo sie aufhören.
CERN und das UNICOS-Framework
Die am besten dokumentierte interne Plattform für Tests und CI in der OT steht in einer Forschungseinrichtung. CERN erzeugt SPS-Code automatisch und testet ihn in einer Pipeline. Die Tests greifen über OPC UA auf SPS-Variablen zu, ohne das Programm zu verändern. Ein Python-Wrapper erlaubt Unit-Tests, und die Simulatoren laufen für Siemens, Schneider und CODESYS.
Software Defined Automation
Ein Münchner Anbieter, der herstellerübergreifend arbeitet: Git-Versionierung für SPS-Code, Fernverwaltung und Backup bestehender Steuerungen von Siemens, Beckhoff, Bosch Rexroth und anderen, dazu virtuelle SPS auf Edge-Servern. Als Anwender nennt das Unternehmen Henkel, SEW-EURODRIVE, Fugro und Cytiva. Die Effizienzgewinne auf der Website sind Anbieterangaben ohne unabhängigen Beleg und als Schätzung zu lesen.
VW CARIAD als Lehrstück
Die Software-Einheit des VW-Konzerns scheiterte weniger an der Technik als an der Organisation. Das Plattform-Team hatte kein eigenes Budget und kein Mandat, die Marken sahen es als Dienstleister. VW stellte die eigene Plattform E3 2.0 nach dem Einstieg bei Rivian ein, seit Oktober 2025 koordiniert CARIAD die Software aus den Partnerschaften mit Rivian und Xpeng. Für OT-Plattformteams ist das die wichtigste Warnung in diesem Artikel.
Bosch Digital Factory als Abgrenzung
Bosch hat mit einer Low-Code-Plattform in vier Jahren über 500 Anwendungen gebaut und damit Schatten-IT abgelöst. Das ist eine App-Plattform für die Fabrik-IT. Mit Platform Engineering für die Steuerungsebene hat es wenig zu tun, und ein belegbares „Backstage für die OT“ gibt es bei keinem Hersteller.
Wie sieht ein Golden Path für SPS-Projekte aus?
Ein Golden Path, manchmal auch Paved Road genannt, ist der vorbereitete Weg vom Commit bis zur Steuerung, den ein Automatisierer nutzt, ohne ihn selbst zu bauen. Er besteht aus einer Projektvorlage, einer geprüften Bausteinbibliothek und einer Pipeline, die kompiliert, in der Simulation testet und den Download erst nach der Freigabe anstößt. Wer davon abweichen muss, darf das. Der Pfad ist nur der schnellste.
- /01Commit
- /02Compile
- /03Simulation
- /04Test
- /05Freigabe
- /06Download
Hardware-in-the-Loop kommt nach der Simulation dazu, wo Timing oder Gerätedetails es verlangen
Wie so eine Pipeline für TIA Portal mit Jenkins konkret aussieht, mit Windows-Build-Agent und Openness, zeigt der Artikel CI/CD für SPS mit TIA Portal und Jenkins.
AISechs Praktiken, die sich bewähren
Die Plattform als Produkt führen, mit Mandat
Ein Plattform-Team braucht Budget, eine Person mit Produktverantwortung und ein Mandat, das über Projektgrenzen reicht. CARIAD zeigt, was ohne das passiert. Die Automatisierungsteams sind die Kunden, das Plattform-Team liefert Pipelines, Backup und Simulation als Dienst.
Golden Paths für SPS-Projekte
Geprüfte, versionierte Bibliotheken mit Funktionsbausteinen nach PLCopen, Projektvorlagen nach IEC 61131-3 und eine fertige Pipeline von Compile bis Download. Der vorbereitete Pfad muss schneller sein als jedes Projekt, das bei null anfängt. Sonst nimmt ihn niemand.
Tests per Self-Service statt Warteliste am Prüfstand
Simulation als Stufe, die jeder Ingenieur selbst anstößt: PLCSIM Advanced oder die CODESYS-Simulation ersetzen den physischen Prüfstand für die meisten Tests, Hardware-in-the-Loop bleibt für Timing und gerätespezifische Fragen. Der erste Ingenieur, der seinen Test nicht mehr am belegten Prüfstand anmeldet, sondern ihn in der Pipeline startet, gibt diesen Komfort nicht mehr her.
Team Topologies in der OT
Ein Plattform-Team, Teams entlang der Linien und Werke und vor allem ein Enabling-Team, das klassische Automatisierer und Platform Engineers zusammenbringt. An diesem Enabling-Team hängt, ob der Skill-Gap in einem Jahr kleiner ist oder größer.
Über Werke und Linien standardisieren
Zentrale Versionierung, wiederverwendbare Bausteine und eine Pipeline-Definition für alle Standorte. Der Nutzen einer Plattform zeigt sich erst, wenn mehrere Werke denselben Golden Path gehen. Ohne diese Standardisierung erleben wir regelmäßig dasselbe: Werk A löst ein Problem, Werk B löst es sechs Monate später noch einmal, und keine der beiden Lösungen überlebt den Weggang ihres Autors.
Auf eine herstellerneutrale Schnittstelle zielen
OPC UA und die Asset Administration Shell statt einer weiteren proprietären Insel. Diese Standards sind heute der aussichtsreichste Weg zu der Daten- und API-Schicht über Herstellergrenzen, die einer OT-Plattform fehlt.
Wo stößt Platform Engineering in der OT an Grenzen?
Dort, wo sich eine SPS nicht wie Software verhält: bei harter Echtzeit, funktionaler Sicherheit und Anlagen, die 25 Jahre laufen. Dazu kommen die eigenen Werkzeuge jedes Herstellers und die Frage, wer über welchen Weg auf welche Steuerung zugreifen darf.
AIJeder Hersteller hat seine eigene Welt
Siemens, Rockwell, Beckhoff, CODESYS: Es gibt kein gemeinsames Gegenstück zu Backstage, und selbst IEC 61131-3 garantiert keine Portabilität zwischen Herstellern. Die App-Stores der Hersteller verstärken die Bindung eher, als sie aufzulösen.
Eine SPS lässt sich nicht per Knopfdruck bereitstellen
Eine Steuerung ist keine Cloud-VM. Virtuelle SPS wie CODESYS Virtual Control oder PLCSIM mildern das, sind aber nicht für jede Safety-, Motion- oder Echtzeitanwendung produktionsreif.
Safety und Echtzeit setzen Grenzen
Funktionale Sicherheit und harte Echtzeit lassen sich nicht beliebig in Container oder Cloud verschieben. Self-Service endet dort, wo Determinismus und Zertifizierung beginnen.
Brownfield und lange Lebenszyklen
Maschinen laufen 20 bis 30 Jahre, mit gemischten Firmware- und Werkzeuggenerationen im selben Schaltschrank. Eine Plattform, die nur neue Anlagen bedient, erreicht den größten Teil der Werkshalle nie.
Skill-Gap und Kultur
Steuerungslogik und Anlagenwissen treffen auf Git, CI/CD und Container. Ohne Enabling-Team und echten Kulturwandel bleibt auch eine gute Plattform ungenutzt.
IEC 62443 und der Nachweis im Audit
Browser-IDE und Remote-Deployment müssen ins Zonen- und Conduit-Modell der IEC 62443 passen. Spätestens im Audit muss belegbar sein, wer über welchen Conduit auf welche Steuerung zugreifen darf. Eine Browser-IDE ohne dieses Mapping ist ein Befund. Und den ROI einer eigenen Plattform belegen Herstellerzahlen nicht.
Welche Standards tragen eine herstellerübergreifende OT-Plattform?
Eine Plattform über Herstellergrenzen braucht eine herstellerneutrale Schicht, und genau die fehlt der OT heute. Am weitesten sind OPC UA für Kommunikation und Tests und die Asset Administration Shell für Daten und Schnittstellen. Margo arbeitet am Edge, IEC 62443 setzt den Sicherheitsrahmen.
Asset Administration Shell
Die Verwaltungsschale ist die international standardisierte, herstellerneutrale Beschreibung eines Assets, mit eigener REST-API (Teil 2) und Registry. Treiber ist die IDTA, die Open-Source-Umsetzung heißt Eclipse BaSyx. Sie ist der beste Kandidat für die fehlende Schnittstelle über Herstellergrenzen, in der Produktion aber noch wenig verbreitet.
OPC UA
Etabliertes Kommunikations- und Informationsmodell. Bei CERN dient es als Testzugang, der SPS-Variablen liest, ohne das Programm zu verändern. Dieses Muster kann jede Testplattform in der OT übernehmen.
Glossar: OPC UAMargo
Offene Initiative der Linux Foundation für Interoperabilität am Edge, gegründet 2024 unter anderem von ABB, Siemens, Rockwell, Schneider Electric und Microsoft. Seit 13. Januar 2026 gibt es Preview Release 1 mit Anwendungsbeschreibung, Flottenverwaltung und Mindestanforderungen an Edge-Geräte. Die erste allgemeine Version ist für 2026 angekündigt, eine stabile API gibt es noch nicht.
IEC 62443
Der Rahmen für OT-Security aus Zonen, Conduits und Security Levels. Für jede Plattform mit Self-Service oder Fernzugriff ist er die Leitplanke, an der sich Remote-Engineering ausrichten muss.
Glossar: IEC 62443Ab wann lohnt sich eine eigene Plattform?
Sobald mehrere Werke oder Linien dieselben Pipelines, Tests und Bibliotheken immer wieder neu bauen. Bei einer einzelnen Anlage ist eine eigene Plattform verfrüht, dort reicht eine saubere Pipeline für die eine Steuerungsfamilie.
DORA beschreibt außerdem eine J-Kurve: Nach den ersten Erfolgen sinken Durchsatz und Stabilität oft wieder, weil die Plattform schneller komplexer wird, als sie sich auszahlt. Wer das weiß, fängt klein an. Ein Golden Path für eine Steuerungsfamilie in einem Werk, gemessen an Durchlaufzeit und Fehlerquote, und erst danach das zweite Werk. Welche Kennzahlen dafür taugen, steht im Artikel DORA-Metriken messen.
AIOb Sie eher ein DevOps-Thema haben oder schon ein Plattform-Thema, hängt vor allem an der Zahl Ihrer Teams. Der Finder ordnet das in zwei Klicks ein.
Welcher Ansatz passt zu Ihrer Organisation?
Platform Engineering ersetzt DevOps nicht, es macht die Arbeitsweise für viele Teams wiederholbar. Ob sich der Aufwand lohnt, hängt an Ihrer Team-Zahl. Beantworten Sie zwei Fragen, und Sie sehen, welcher Ansatz zu Ihrer Organisation passt.
Wie viele Entwicklungs-/Engineering-Teams?
Ob sich eine eigene Plattform für Ihre Werke rechnet, lässt sich in einem fachlichen 30-Minuten-Erstgespräch klären. Wir gehen Ihre Ausgangslage durch, und die Einschätzung behalten Sie in jedem Fall.
30 Minuten · unverbindlich · kein Vertriebsgespräch
Häufige Fragen zu Platform Engineering in der OT
Was ist der Unterschied zwischen DevOps und Platform Engineering?
DevOps ist die Arbeitsweise, die Entwicklung und Betrieb zusammenbringt. Platform Engineering ist die organisatorische Antwort darauf, dass „you build it, you run it“ einzelne Teams überlastet: Ein eigenes Plattform-Team baut eine interne Entwicklerplattform mit Self-Service und Golden Paths. Platform Engineering ersetzt DevOps nicht, es macht die Arbeitsweise für viele Teams wiederholbar.
Ersetzt Platform Engineering DevOps?
Nein. Platform Engineering baut auf DevOps auf und nimmt den Teams wiederkehrende Arbeit an Pipelines und Umgebungen ab, die Arbeitsweise dahinter bleibt dieselbe. Auch KI ersetzt DevOps nicht: Der DORA-Bericht 2025 zeigt, dass KI-Werkzeuge vor allem dort wirken, wo eine gute interne Plattform schon steht.
Was ist der Unterschied zwischen einem DevOps Engineer und einem Platform Engineer?
Ein DevOps Engineer arbeitet meist in oder mit einem Produktteam und baut dessen Pipelines und Betriebsabläufe. Ein Platform Engineer baut die gemeinsame Plattform, die viele Teams nutzen, und behandelt diese Teams als interne Kunden. In der Industrie kommt beim Platform Engineer das Verständnis für SPS-Engineering-Systeme, Simulation und Freigabeprozesse dazu.
Was macht ein Plattform-Team in der Automatisierung?
Es stellt den Automatisierungsteams Projektvorlagen, geprüfte Bausteinbibliotheken, Pipelines mit Simulationstests und das Backup der Steuerungsstände als Dienst bereit. Die Teams an den Linien und Werken bedienen diese Plattform selbst, das Plattform-Team pflegt sie wie ein Produkt mit Roadmap und Rückmeldungen seiner Nutzer.
Ist eine DevOps-Plattform wie GitLab schon Platform Engineering?
Nein. Eine DevOps-Plattform wie GitLab oder Azure DevOps ist ein gekauftes Produkt, das Repository, CI/CD und Registry bündelt. Platform Engineering beginnt erst, wenn ein Team darauf Golden Paths für die eigenen Projekte baut und diese interne Entwicklerplattform als Produkt pflegt. In der OT muss die Plattform zusätzlich bis zur Steuerung reichen, mit Compile, Simulation und Download im Golden Path.
Lässt sich Platform Engineering auf SPS und PLC anwenden?
Teilweise. Self-Service, Golden Paths und die Plattform als Produkt passen auch auf Steuerungscode, ein herstellerübergreifendes Gegenstück zu Backstage gibt es für die OT aber nicht. Was heute trägt, sind Git für SPS-Code (seit TIA Portal V21 auch mit Textformat für Bausteine), Tests in der Simulation mit PLCSIM Advanced oder CODESYS und zentrales Lifecycle-Management über viele Controller.
Was ist eine Internal Developer Platform in der Industrie?
Sie stellt Automatisierungsingenieuren geprüfte Projektvorlagen, fertige CI/CD-Pipelines, Simulationsumgebungen und versionierte Bausteinbibliotheken zum Selbstbedienen bereit. Statt jedes SPS-Projekt neu aufzusetzen, wählen die Teams einen vorbereiteten, abgesicherten Weg, den Golden Path.
Braucht die OT ein internes Entwicklerportal oder eine interne Entwicklerplattform?
Zuerst die Plattform. Das interne Entwicklerportal ist nur die Oberfläche; ohne Pipelines, Simulationsumgebungen und geprüfte Bausteinbibliotheken dahinter löst kein Knopf im Portal etwas aus. In der Automatisierung kommt deshalb zuerst ein Golden Path, der Steuerungscode kompiliert, simuliert und ausrollt, und danach eine Oberfläche darüber.
Gibt es ein Backstage für die OT?
Nein, kein etabliertes Gegenstück über Herstellergrenzen. Die App-Stores der Hersteller, etwa Siemens Industrial Edge, Bosch Rexroth ctrlX OS oder Phoenix Contact PLCnext, sind Edge-Marktplätze mit Geräteverwaltung und verstärken die Bindung an den Hersteller. Am nächsten an einer Plattform sind der CODESYS Automation Server für den Lifecycle und herstellerneutrale Werkzeuge wie Software Defined Automation.
Welche Standards helfen bei der Standardisierung in der OT?
OPC UA als Kommunikations- und Testschicht, die Asset Administration Shell (Verwaltungsschale) als herstellerneutrale API- und Datenschicht und die Margo-Initiative für Interoperabilität am Edge. Die Verwaltungsschale gilt als aussichtsreichster Kandidat für die fehlende Schnittstelle über Herstellergrenzen. Margo hat im Januar 2026 Preview Release 1 veröffentlicht und ist noch im Aufbau.
Wann lohnt sich eine eigene Plattform in der Industrie?
Sobald mehrere Werke oder Linien immer wieder ähnliche Pipelines, Tests und Bibliotheken neu bauen. Bei einer einzelnen Anlage ist eine eigene interne Entwicklerplattform meist verfrüht, dort sind eine saubere Pipeline, eine Hersteller-Plattform oder ein herstellerneutrales Werkzeug die pragmatischere Antwort.
Wie geht es bei Ihnen mit Platform Engineering weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
Platform Engineering: Der nächste Schritt nach DevOps
Self-Service-Plattformen, Golden Paths und Internal Developer Platforms.
GitOps in der Industrie: SPS/PLC versionieren & ausrollen
Was GitOps in der SPS-Entwicklung und am Industrie-Edge möglich macht.
IT/OT-Kulturwandel: Zwei Welten zusammenbringen
Wie Automatisierer und Software-Teams zu einer Organisation werden.
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance