12. Okt. 2026
Software Defined Industry
Warum die nächste Produktivitätslücke in der Software entsteht
Die deutsche Industrie baut exzellente Maschinen. Daran liegt es nicht. Trotzdem kommen viele Unternehmen bei Produktivität, Anpassungsgeschwindigkeit und Skalierung nur langsam voran. Der Engpass sitzt heute oft an einer anderen Stelle: in einer Produktionslogik, die jede Verbesserung wieder zum Einzelprojekt macht.
Hier setzt Software Defined Industry an. Der Begriff klingt technisch, ist im Kern aber eine Managementfrage. Es geht um die Fähigkeit, industrielle Funktionen schneller zu verändern, mehrfach zu nutzen und über Jahre weiterzuentwickeln. Wer das beherrscht, gewinnt Spielraum bei Kosten, Time-to-Market und Servicegeschäft. Wer jede neue Anforderung weiter mit neuer Verdrahtung, neuem Engineering und zusätzlicher Sonderlogik beantwortet, wird es schwer haben.
01 — Einordnung
Das Produktivitätsparadox des Maschinenbaus
Im Maschinenbau war die Rollenverteilung lange klar: Die Maschine stand im Mittelpunkt, die Software hatte zu dienen. Sie steuerte, regelte, visualisierte. Der eigentliche Wert entstand in Mechanik, Elektrik und Automatisierungstechnik. Software war notwendig, aber selten der Ort, an dem der Durchbruch lag.
Genau das verschiebt sich gerade. Neue Funktionen entstehen immer öfter über Software. Anpassungen, Optimierungen, Assistenzsysteme, Security-Updates oder digitale Services werden nicht mehr automatisch über neue Hardware gelöst. Darin liegt das Produktivitätsparadox: Unsere Industrie automatisiert seit Jahrzehnten auf hohem Niveau und schafft es trotzdem zu selten, Verbesserungen breit wirksam zu machen.
Der Grund ist einfach. In vielen Produktionsumgebungen steckt die Logik fest in einzelnen Anlagen, Projekten und proprietären Strukturen. Wissen ist eingebaut, aber kaum übertragbar. Jede Integration geht ihren eigenen Sonderweg. Jede Optimierung wird wieder zum neuen Eingriff. Das Ergebnis kennt fast jeder aus dem Alltag: hoher Engineering-Einsatz, viele gute Einzellösungen, wenig Skaleneffekt.
Im Digitalen spielt der Maschinenbau deshalb oft unter seinen Möglichkeiten. Es fehlt nicht an Ingenieurskunst. Es fehlt an einer Architektur, die Wiederverwendung zulässt. Während die USA und China massiv in Softwarekompetenz, Plattformlogik und datengetriebene Produktionsmodelle investieren, zehrt Europa noch stark von seinem Hardware-Know-how und lässt einen Teil des Produktivitätspotenzials liegen. Künftig entscheidet also nicht nur die Qualität der Maschine, sondern auch die Geschwindigkeit, mit der sich Produktion per Software verändern lässt.
02 — Geschäftsmodell
Software Defined: Der Wert entsteht nach dem Kauf
Andere Branchen haben diesen Punkt längst verstanden. Beim Auto, beim Smartphone oder in der Medizintechnik endet der Wert eines Produkts nicht mit der Auslieferung der Hardware. Er wächst weiter: über Software, Updates und neue Funktionen.
Auf die Industrie übertragen heißt das: Produktionsfähigkeiten werden von einzelner Hardware gelöst und als wiederverwendbare Softwarebausteine beschrieben. Damit ändert sich der Blick grundlegend. Eine Maschine wird weniger über Hersteller, Typ oder Steuerung betrachtet, sondern stärker über das, was sie zuverlässig leisten kann: greifen, prüfen, montieren, transportieren, dosieren, etikettieren.
Das ist nicht nur Architekturarbeit. Strategisch geht es um mehr. Die Leitfrage verschiebt sich: weg von der reinen Maschinenqualität, hin zur Fähigkeit, die eingesetzte Software schnell, sicher und wirtschaftlich weiterzuentwickeln.
Für Maschinenbauer und Anlagenbauer hat das direkte Folgen für das Geschäftsmodell. Früher endete die Wertschöpfung im Wesentlichen mit der Inbetriebnahme. Heute beginnt an diesem Punkt oft erst die eigentliche Hebelwirkung. Die Maschine wird zur Plattform für Erweiterungen, Assistenzfunktionen, Services, KI-Anwendungen und laufende Optimierung. Wer heute Maschinen entwickelt, entscheidet damit auch über die digitalen Erlöspotenziale der nächsten Jahre. Es geht also nicht nur um besseres Engineering. Es geht um die Frage, wie über den gesamten Lebenszyklus neuer Kundennutzen entsteht.
03 — Dringlichkeit
Warum das jetzt Chefsache ist
Dass dieses Thema oben auf die Agenda gehört, hat unter anderem diese vier Gründe.
1. Volatilere Märkte
Varianten nehmen zu, Losgrößen schwanken, Materialien ändern sich kurzfristig. Viele Unternehmen müssen heute in Tagen reagieren, nicht in Quartalen. Wenn jede Umrüstung sofort tief ins Projektgeschäft zieht, wird aus Marktbewegung direkt interner Aufwand.
2. Fachkräftemangel und Wissensbindung
In vielen Werken steckt das wertvollste Wissen in wenigen Köpfen. Der erfahrene Inbetriebnehmer erkennt Muster, die in keiner Dokumentation stehen. Der Servicetechniker hört ein Geräusch und weiß sofort, wo es kritisch wird. Dieses Wissen ist Gold wert. Es hilft aber nur begrenzt, solange jede Maschine ihre eigene Logik, ihr eigenes Datenbild und ihren eigenen Sonderfall mitbringt. Wiederverwendbare Maschinenskills und saubere Datenmodelle machen aus individuellem Erfahrungswissen ein belastbares Unternehmensasset.
3. Regulierung und Security
Mit dem Cyber Resilience Act wird Updatefähigkeit über den Lebenszyklus zur Pflicht. Security ist damit keine nachgelagerte Zusatzaufgabe mehr. Wer keine softwarefähige Architektur hat, zahlt später doppelt: mit höheren Kosten, längeren Zyklen und mehr Risiko im Feld.
4. Verfügbarkeit und Stillstandskosten
Jede Stunde ungeplanter Stillstand kostet bares Geld. Trotzdem dauert die Fehlersuche in vielen Betrieben zu lange: Fehlercodes ohne Kontext, Diagnose nur vor Ort, Abhängigkeit von wenigen Spezialisten. Eine softwaredefinierte Maschine liefert Zustand, Ursache und betroffenen Auftrag maschinenlesbar mit. Service wird schneller, Fernwartung praxistauglich und das Wissen aus jedem gelösten Störfall fließt zurück ins System, statt im Kopf des Einzelnen zu bleiben.
04 — Strategie
Vom Use Case zum Fundament
Viele Digitalisierungsprogramme scheitern an einem bekannten Muster. Sie finanzieren Einzelfälle. Ein Dashboard hier, eine Analytics-Lösung dort, vielleicht ein KI-Pilot im Service. Lokal kann das sinnvoll sein. Strukturell wächst damit aber oft die Komplexität: neue Schnittstellen, neue Datenhaltung, neue Dienstleister, neue Abhängigkeiten.
Das Problem liegt selten im einzelnen Use Case. Das Problem ist der fehlende Unterbau.
Software Defined Industry setzt deshalb früher an. Standardisierte Schnittstellen, klare semantische Datenmodelle und gekapselte Maschinenfunktionen schaffen ein Fundament, das wiederverwendbar ist. Der erste Anwendungsfall bleibt oft der teuerste. Der Hebel entsteht danach. Wenn der zweite, dritte und zehnte Schritt schneller und günstiger werden, beginnt sich die Investition zu rechnen.
Der eigentliche Business Case steckt also nicht im Pilot. Er steckt in der Wiederholung.
05 — Technologie
KI braucht Ordnung, keine Magie
Rund um agentische KI und autonome Produktionslogik ist viel Bewegung im Markt. Das ZVEI-Positionspapier zur Software Defined Industry beschreibt zu Recht, wohin die Reise gehen kann: KI-Systeme, die planen, koordinieren, priorisieren und in klaren Grenzen selbst handeln.
Die Richtung ist plausibel. In der Praxis wird das Thema nur oft zu früh aufgerufen.
KI kann fehlende Struktur nicht kompensieren. Agenten können nur sinnvoll agieren, wenn Fähigkeiten, Zustände, Regeln und Verantwortlichkeiten sauber digital beschrieben sind. Wo Maschinendaten in Excel-Dateien, Netzlaufwerken und Projektsonderlösungen verstreut liegen, entsteht keine belastbare autonome Fabrik. Dort entsteht bestenfalls eine eindrucksvolle Demo.
Wer heute in Software Defined Industry investiert, kauft deshalb kein KI-Versprechen. Er baut die operative Grundlage, auf der KI später echten Mehrwert liefern kann.
06 — Praxis
Wie der Einstieg in der Praxis aussieht
Der Einstieg beginnt sinnvollerweise nicht bei Autonomie, sondern bei Architektur und Nutzen. Aus unseren Projekten im Maschinen- und Anlagenbau hat sich ein pragmatischer Fünf-Stufen-Pfad bewährt, an dessen Ende die Software Defined Industry steht:
1. Digitales Fundament schaffen
Maschinen, Bestandsanlagen und Anwendungen über standardisierte Schnittstellen und Datenmodelle anbinden. Wo nötig, helfen Edge-Adapter statt Austauschprogramme.
2. Transparenz herstellen
Daten kontextualisieren, Zustände sichtbar machen, Abweichungen sauber einordnen. Erst dann werden Entscheidungen belastbar.
3. Funktionen kapseln
Maschinenfähigkeiten als wiederverwendbare Softwarebausteine beschreiben: greifen, prüfen, montieren, transportieren. Hier entsteht der Kern von Software Defined Industry.
4. Prozesse gezielt verbessern
Engpässe erkennen, Rüstzeiten reduzieren, Support beschleunigen, Entscheidungen besser vorbereiten.
5. Wiederverwendung skalieren
Bausteine auf weitere Maschinen, Linien und Standorte übertragen. Jeder folgende Schritt wird schneller und günstiger. Genau hier beginnt sich die Investition zu rechnen.
Diese Stufen sind keine starre Baufolge, sondern beschreiben Abhängigkeiten: Wiederverwendung ohne Datenordnung funktioniert nicht, Prozessverbesserung ohne Transparenz wird zum Risiko. Innerhalb dieser Logik bleibt viel Raum für die eigene Priorisierung. Was am Anfang stehen muss, ist etwas anderes: ein klares Zielbild.
Ausblick: KI-Agenten als Königsklasse
Damit steht die Software Defined Industry auch ohne einen einzigen Agenten. Genau hier beginnt die Königsklasse: Sind Daten und Fähigkeiten strukturiert verfügbar, können KI-Agenten zunächst empfehlend und später in klar abgegrenzten Grenzen auch handelnd eingesetzt werden. Produktagenten können Anforderungen und Arbeitsschritte repräsentieren. Ressourcenagenten bilden Maschinen, Module oder Arbeitsplätze ab und berücksichtigen Verfügbarkeit sowie Auslastung. Serviceagenten können Dienste oder Daten über System- und Unternehmensgrenzen vermitteln.
In einem möglichen Ablauf sucht ein Produktagent nach einer Ressource mit der benötigten Fähigkeit. Geeignete Ressourcen melden Kapazitäten zurück. Anschließend wird ein Produktionsschritt geplant und über den passenden Skill ausgeführt. Sprachmodelle können den Informationszugriff oder die Kommunikation unterstützen. Die operative Kontrolle benötigt jedoch feste Berechtigungen, Validierung, Monitoring und sichere Rückfallmechanismen.
Agenten sind das i-Tüpfelchen. Das Fundament bleibt die Software Defined Industry.
Wie der Weg dorthin in der Praxis aussieht, zeigt ein Beispiel.
07 — Praxisbeispiel
Ein Praxisbeispiel: Erst die Vision, dann die Schritte
Für einen Maschinenbauer haben wir eine modulare, CRA-konforme Plattformarchitektur aufgebaut, die Entwicklung, Engineering und Laufzeit der Maschinensoftware zusammenführt. Im Mittelpunkt standen drei strategische Ziele: geringere Abhängigkeit von einzelnen Hardware-Lieferanten, eine deutlich bessere digitale User Experience für den Kunden und eine durchgängige CRA-Compliance von der Entwicklung bis in den Betrieb.
Der eigentliche Dreh- und Angelpunkt des Projekts war aber etwas anderes: das Zielbild. Bevor die erste Zeile Code geschrieben wurde, haben wir gemeinsam mit dem Kunden eine klare Vision der künftigen Maschinenplattform beschrieben. Wie sieht die Zielarchitektur aus? Welche Fähigkeiten soll die Maschine in fünf Jahren haben? Wie werden Updates, Services und neue Funktionen ausgerollt? Dieses Bild war der Kompass für alles Weitere.
Das ist aus meiner Sicht der Unterschied zur klassischen Projektlogik. Mit einem verbindlichen Zielbild vor Augen konnten wir Schritt für Schritt dorthin arbeiten und gleichzeitig unterwegs nach links und rechts schauen: neue Technologien bewerten, Anforderungen aus den Business Units aufnehmen, Prioritäten verschieben, ohne die Richtung zu verlieren. Die Reihenfolge der einzelnen Umsetzungsschritte war dabei erstaunlich flexibel. Nicht flexibel war das Fundament: standardisierte Schnittstellen, saubere Datenmodelle, gekapselte Funktionen. Auf diesem Unterbau ließen sich Bausteine in der Reihenfolge realisieren, die dem Geschäft gerade am meisten brachte.
Die Erfahrung aus diesem Projekt lässt sich auf einen einfachen Satz bringen: Ohne Zielbild wird jede Roadmap zur Zufallsstrecke. Mit Zielbild wird jeder einzelne Schritt zum Beitrag, auch wenn sich die Reihenfolge ändert.
08 — Checkliste
Was Geschäftsführer jetzt klären sollten
Software Defined Industry ist kein IT-Projekt am Rand. Es betrifft Produktstrategie, Engineering, Service, Security und künftige Erlösmodelle zugleich. Deshalb helfen drei einfache Fragen für die Standortbestimmung:
Wie lange dauert die Integration einer neuen Maschine in MES und ERP?
Wenn die Antwort in Monaten gemessen wird, zahlt das Unternehmen bei jedem Projekt erneut die Unikat-Kosten.
Wo bleibt das Know-how der besten Leute?
Wenn es vor allem in Köpfen steckt und kaum in wiederverwendbaren Funktionen, Modellen und Standards, ist das ein Skalierungsrisiko.
Wie belastbar ist die CRA-Readiness?
Wenn Updatefähigkeit und Security-Lifecycle noch nicht architektonisch mitgedacht sind, wird es spätestens 2027 teuer.
Die bessere Leitfrage lautet deshalb nicht, wie autonom die Fabrik einmal werden könnte. Autonomie ist eine mögliche Ausbaustufe, aber nicht das Ziel an sich. Das Ziel ist Software Defined Industry. Ihre Leitfrage ist: Welche Veränderung muss künftig schneller, sicherer und mit weniger Engineering-Aufwand möglich sein?
Fazit
Die Industrie braucht keinen Hardware-Abgesang. Im Gegenteil. Starke Hardware bleibt der Kern industrieller Wertschöpfung. Aber sie reicht allein nicht mehr aus, wenn Produktivität, Anpassungsgeschwindigkeit und Resilienz steigen sollen.
Software Defined Industry ist der logische nächste Schritt. Produktion wird dabei als veränderbares Softwaresystem gedacht, mit klar beschriebenen Fähigkeiten, sauberen Schnittstellen und wiederverwendbaren Bausteinen. Das reduziert Reibung im Tagesgeschäft und eröffnet gleichzeitig neue Geschäftsmodelle über den gesamten Lebenszyklus der Maschine.
Die Technologie ist verfügbar. Die Standards sind weit genug. Die offene Frage ist nicht mehr, ob sich dieser Wandel durchsetzt. Die offene Frage ist, wer ihn im eigenen Haus früh genug in eine belastbare Architektur übersetzt.
09 — FAQ
Häufig gestellte Fragen
Was ist Software Defined Industry?
Software Defined Industry beschreibt industrielle Systeme, deren Funktionen und Abläufe über modulare Software, standardisierte Datenmodelle und offene Schnittstellen definiert werden. Bestehende Anlagen müssen dafür nicht ersetzt werden. Adapter und Edge-Komponenten ermöglichen eine schrittweise Integration.
Wie unterscheidet sich SDI von Industrie 4.0?
Industrie 4.0 hat Maschinen vernetzt und Daten verfügbar gemacht. SDI geht einen Schritt weiter und rückt die softwareseitige Veränderbarkeit sowie die Wiederverwendung industrieller Funktionen in den Mittelpunkt.
Funktioniert SDI auch ohne Agenten?
Ja. Das Fundament von SDI bildet die Entkopplung von Software und Hardware durch standardisierte Schnittstellen und wiederverwendbare Funktionsbausteine. Agentische Systeme und KI sind keine Grundvoraussetzung, sondern eine optionale Erweiterung, um hochflexible Abläufe autonom zu optimieren. Auch ohne Agenten gewinnt SDI: schnellere Integration, weniger Engineering-Aufwand und Updatefähigkeit über den gesamten Lebenszyklus.
Welche Rolle spielt die Verwaltungsschale?
Sie ist so etwas wie der maschinenlesbare Steckbrief eines Assets: Eigenschaften, Zustände, Schnittstellen und Fähigkeiten liegen in einer standardisierten Struktur vor. Damit kann Software eine Maschine „verstehen“, ohne dass jemand vorher Dokumentation wälzen und Datenpunkte manuell zuordnen muss. Für das Fundament von SDI ist die Verwaltungsschale einer der wichtigsten Bausteine, weil sie genau die Wiederverwendbarkeit ermöglicht, auf der alles andere aufbaut.
Müssen bestehende Anlagen ersetzt werden?
Nein, in der Regel nicht. SDI ist ein Evolutionspfad, kein Rückbau. Bestehende Maschinen werden über Edge-Komponenten und Adapter angebunden, die Steuerungslogik bleibt zunächst wo sie ist. Ersetzt wird nur dort, wo es der Nutzen rechtfertigt. Genau das unterscheidet den Ansatz vom klassischen Rip-and-Replace: Die Modernisierung folgt dem Geschäftsnutzen, nicht dem Technologiezyklus.
Wo sollten Unternehmen beginnen?
Am besten bei einem klar abgegrenzten Engpass mit erkennbarem Geschäftsnutzen, zum Beispiel bei einer häufigen Umrüstung oder einer aufwendigen Maschinenintegration. Entscheidend ist, dass der Pilot kein isoliertes Projekt bleibt. Datenmodelle, Schnittstellen und Sicherheitsregeln sollten von Anfang an auf Wiederverwendung ausgelegt sein.
Autoren
Marco Wanner
Christian Heinrich