Prescriptive Engineering Wie KI in belastbare Engineering-Prozesse eingebettet wird

Anbieter zum Thema

Parametric Technology GmbH

MicroConsult Academy GmbH

MES Electronic Connect GmbH & Co. KG

DMB Technics AG

KI erkennt Auffälligkeiten, priorisiert Informationen oder liefert Prognosen. Sie greift jedoch meist nicht in die Prozesse ein, in denen über Anforderungen, Varianten, Änderungen und Freigaben entschieden wird. Genau an dieser Stelle wird Prescriptive Engineering relevant.

Gerade im Engineering reicht es nicht aus, KI isoliert als Analysewerkzeug einzusetzen, weil Entwicklung strukturell anders funktioniert als klassische Datenanalyse. Entscheidungen entstehen entlang von Abhängigkeiten zwischen Anforderungen, Systemarchitektur, Softwareständen, Testfällen und Konfigurationen. Änderungen betreffen selten nur ein einzelnes Element, sondern wirken auf mehrere Ebenen und müssen technisch wie regulatorisch nachvollziehbar abgesichert werden. Besonders sichtbar wird das bei softwaredefinierten Produkten, in denen Hardware, Software, Variantenlogik und Lieferkette eng miteinander verknüpft sind.

Prescriptive Engineering beschreibt einen methodischen Rahmen, in dem KI nicht bei der Auswertung stehen bleibt, sondern aus Daten, Regeln und technischem Kontext konkrete Handlungsempfehlungen für den weiteren Entwicklungsprozess ableitet und in kontrollierte Abläufe zurückführt.

Warum isolierte Use Cases nicht skalieren

Viele KI-Projekte bleiben im Engineering deshalb klein, weil sie als Einzellösung eingeführt werden. Ein Modell wertet Felddaten aus, ein anderes priorisiert Anforderungen, ein drittes erkennt Auffälligkeiten in Testdaten. Jeder dieser Anwendungsfälle kann sinnvoll sein. Ein durchgängiger Engineering-Prozess entsteht daraus aber noch nicht. Der Grund liegt nicht in der Qualität des einzelnen Modells, sondern in der fehlenden Kopplung zwischen KI-Ergebnissen und den Strukturen, in denen technische Entscheidungen tatsächlich getroffen werden.

Ein typisches Beispiel ist die Analyse von Sensordaten aus dem Feld. Erkennt ein Modell thermische Auffälligkeiten in einer Steuergerätekomponente, ist das zunächst nur ein Signal. Solange dieses Signal nicht mit den betroffenen Anforderungen, der konkreten Softwareversion, der verbauten Hardware, den zugehörigen Testfällen und möglichen Änderungsprozessen verknüpft wird, bleibt es isoliert. Es liefert Erkenntnis, aber noch keine belastbare Grundlage für eine technische Maßnahme.

Welche Architektur Prescriptive Engineering voraussetzt

Die eigentliche Skalierungsfrage ist deshalb architektonisch. In den meisten Unternehmen liegen Anforderungen im ALM, Stücklisten und Konfigurationen im PLM, Lieferinformationen im ERP und Betriebsdaten in IoT oder Service-Systemen. Solange diese Informationen nur nebeneinander existieren, bleibt auch KI fragmentiert. Prescriptive Engineering setzt voraus, dass relevante Objekte über Systemgrenzen hinweg konsistent verknüpft sind und sich Änderungen in ihrem fachlichen Zusammenhang bewerten lassen.

Dafür braucht es keine monolithische Plattform, sondern eine Integrationsarchitektur mit stabilen Objekt-IDs, versionsfähigen Datenmodellen, bidirektionalen Referenzen und klar definierten Übergabepunkten zwischen ALM, PLM, ERP und Service-Systemen. Erst wenn Anforderungen, Konfigurationen, Changes, Teststände und Felddaten in einem gemeinsamen Kontext auswertbar sind, kann KI Auswirkungen belastbar einordnen. Genau an dieser Stelle wird der Intelligent Product Lifecycle (IPL) zum entscheidenden Fundament.

Er verknüpft die relevanten Informationen entlang des gesamten Produktlebenszyklus, von der ersten Anforderung über Systemmodell, Softwarestand und Stückliste bis hin zum Betrieb im Feld. Änderungen lassen sich dadurch nicht isoliert, sondern im Kontext einer konkreten Produktkonfiguration bewerten. Das ist die Voraussetzung dafür, dass aus einer Analyse eine technisch verwertbare Empfehlung wird.

Wie aus Analyse konkrete nächste Schritte werden

Prescriptive Engineering baut auf dieser Struktur auf. Während klassische KI in erster Linie Muster erkennt, verbindet Prescriptive Engineering Erkenntnisse mit Anforderungen, implementierten Funktionen, Variantenständen, Testfällen und Change-Prozessen. Dadurch lässt sich nicht nur feststellen, dass eine Abweichung vorliegt, sondern auch, welche nächsten Schritte fachlich naheliegen.

Wird beispielsweise eine Leistungsabweichung im Feld erkannt, reicht der Hinweis auf die Abweichung allein nicht aus. Entscheidend ist, ob sie auf eine bestimmte Softwareversion, eine Hardware-Revision, eine fehlerhafte Anforderung, einen unzureichenden Testfall oder auf ein geändertes Zulieferteil zurückzuführen sein könnte. Prescriptive Engineering ordnet solche Signale in den technischen Zusammenhang ein und bereitet daraus nachvollziehbare Handlungsvorschläge vor, etwa einen Change-Request, die Anpassung einer Anforderung, zusätzliche Tests oder die Prüfung alternativer Komponenten.

Welche Rolle Agentic AI dabei übernimmt

Damit dieser Ansatz im Alltag funktioniert, muss Kontext über mehrere Systeme hinweg zusammengeführt werden. Hier liegt die Rolle von Agentic AI. KI-Agenten ersetzen keine formale Engineering-Entscheidung, sie übernehmen aber die kontextbezogene Orchestrierung von Informationen entlang der Toolchain. Sie verknüpfen Daten aus verschiedenen Quellen, bewerten ihre Relevanz für den jeweiligen Fall und bereiten daraus strukturierte Entscheidungsvorlagen vor.

Ein KI-Agent kann etwa Wartungsdaten eines Moduls mit den funktionalen Anforderungen im ALM, der physischen Konfiguration in der PLM-Stückliste und dem aktuellen Lieferstatus im ERP in Beziehung setzen. Auf dieser Grundlage lässt sich bewerten, ob eine Abweichung eher auf ein Designproblem, eine bestimmte Konfiguration oder ein verfügbares Substitut in der Lieferkette hindeutet. Ohne diese Form der Orchestrierung bliebe Prescriptive Engineering ein theoretisches Regelwerk. Erst durch die systemübergreifende Kontextintegration wird der Ansatz operativ nutzbar.

Warum ALM-Strukturen die operative Absicherung liefern

Handlungsempfehlungen werden im Engineering nicht dadurch belastbar, dass sie schnell erzeugt werden, sondern dadurch, dass sie kontrolliert weiterverarbeitet werden können. Deshalb spielen ALM-Strukturen eine zentrale Rolle. Sie bilden den Arbeitsraum, in dem Anforderungen, Änderungen, Reviews, Testfälle und Traceability zusammenlaufen. Ein durch KI vorbereiteter Vorschlag wird dort nicht automatisch umgesetzt, sondern als Requirement-Update oder Change-Request in einen geregelten Prozess überführt, etwa in ALM-Systemen wie Codebeamer.

Gerade hier zeigt sich der praktische Wert einer prozessintegrierten KI. Wird eine Änderung an Softwareparametern vorgeschlagen, lassen sich die betroffenen Sicherheitsanforderungen, Testfälle und Freigabeschritte unmittelbar identifizieren. Die formale Entscheidung verbleibt im Engineering-Prozess. KI priorisiert, korreliert und empfiehlt, die Freigabe bleibt an etablierte Review- und Change-Strukturen gebunden. So können Änderungszyklen verkürzt werden, ohne Nachvollziehbarkeit, Compliance und technische Disziplin zu schwächen.

Prescriptive Engineering als Antwort auf komplexe Produktentwicklung

Je stärker Produkte softwaredefiniert, variantenreich und vernetzt werden, desto weniger tragen isolierte KI-Experimente und fragmentierte Datenlandschaften. Prescriptive Engineering ist deshalb kein Zusatz zu bestehenden Analysewerkzeugen, sondern eine methodische Antwort auf die Frage, wie KI in belastbare Engineering-Prozesse eingebettet werden kann. Der entscheidende Hebel liegt nicht im einzelnen Modell, sondern in der Architektur, die Kontext, Traceability und kontrollierte Weiterverarbeitung ermöglicht.

Unternehmen, die diese Durchgängigkeit herstellen, nutzen KI nicht nur zur Beobachtung komplexer Systeme, sondern zur fundierten Vorbereitung technischer Entscheidungen. Genau darin liegt der Unterschied zwischen punktueller Automatisierung und prozesswirksamer KI im Engineering.

*Arian van Hülsen ist Director Solutions Consulting & Global AI Champion bei PTC

(mc)

(ID:50877370)