Wir haben in den letzten 6 Wochen 20 Interviews mit Industrieunternehmen geführt, um zu verstehen, warum sich viele Unternehmen noch mit der Automatisierung im Engineering und Industrial Engineering schwertun. Wir wollten verstehen, wo sie beim Einsatz von KI stehen und welche Herausforderungen sie bei der Automatisierung haben. Wir waren dabei nicht ganz selbstlos: Wir wollten verstehen, welche Anforderungen an unsere Plattform gestellt werden, um unsere Produktentwicklung gezielt vorantreiben zu können.

Die Ergebnisse aus den Interviews haben uns dann doch überrascht. Um Ihnen die Entscheidung zu erleichtern, ob es sich lohnt weiterzulesen, hier ein kleiner Vorgriff auf die wichtigsten Erkenntnisse:

1. PLM automatisiert nicht durchgängig – auch wenn viele das hoffen.
   
   Nur 4 von 20 Unternehmen nutzen PLM umfassend. Und selbst diese kämpfen im Sonderproduktgeschäft weiterhin mit hohem manuellem Aufwand. PLM ist eine gute Grundlage aber kein E2E-Automatisierungsmotor.

   
   

2. KI ist längst im Engineering angekommen – aber nur im Copy-Paste-Modus.

   Die Mitarbeiter nutzen LLMs (meist private Accounts) schon regelmäßig für die Arbeit. Täglich. Aber nicht integriert, nicht abgesichert, nicht governancefähig. Zwischen strategischer KI-Vision und operativer Realität klafft eine große Lücke.

   
   

3. Einige Automatisierungsfunktionen existieren – werden aber nicht genutzt.
   
   Vermeintlich gibt es sie schon in den großen Engineering-Suiten. Allerdings waren für viele die Nutzerfreundlichkeit und die daran anschließenden Möglichkeiten zur Automatisierung nicht ausreichend oder die Einstiegshürden zu hoch.

   
   

4. Generische Workflowautomatisierungsplattformen stoßen im Engineering schnell an Grenzen.

   Mangelndes Engineering-Know-how sowie hohe Anforderungen an Security und Governance sind Gründe, weshalb generische Workflowautomatisierungslösungen (wie n8n) nicht so richtig Fuß fassen können.

   
   

5. Automatisierung ist im Maschinenbau kein IT-Projekt.

   Alle Gesprächspartner waren sich einig: Wenn Engineering und Industrial Engineering nicht selbst automatisieren, wird’s schwierig. Der IT fehlen das Domänenwissen und die Ressourcen.

I. Sind die Erkenntnisse auf Sie übertragbar?

Damit Sie besser einschätzen können, ob die Erkenntnisse auf Ihr Unternehmen übertragbar sind, hier eine kurze Zusammenfassung, mit wem wir gesprochen haben: Die Unternehmen hatten einen Jahresumsatz zwischen 50 Mio. und 3 Mrd. € und kamen überwiegend aus dem Maschinen- und Anlagenbau sowie der industriellen Komponenten- und Systemfertigung. Gemeinsam sind ihnen eine hohe technische Komplexität, ausgeprägte Variantenvielfalt, kundenspezifische Ausprägungen und ein hoher Engineering-Anteil. Die Bandbreite reicht von großen Batteriespeichersystemen über Abfüll- und Verpackungsanlagen, industrielle Mischer, kundenspezifische Hochleistungsmetallteile und individuelle Schaltschranksysteme bis hin zu Fenster- und Beschlaglösungen, Baggern, sensorbasierten Sortier- und Transportlösungen sowie Präzisionswerkzeugen. Die Gesprächspartner waren CTOs, Leiter Engineering, COOs, Leiter Industrial Engineering sowie Digitalisierungsverantwortliche.

 II. Oft entstehen Varianten noch in Einzelfallarbeit anstatt in einem automatisierten Prozess – Ingenieure arbeiten weniger als 50 % wertschöpfend.

Im ersten Schritt ging es uns darum zu verstehen, was die fachlichen Herausforderungen sind – ganz losgelöst von KI & Co. Denn Technologie ist nur Mittel zum Zweck. Hauptsache, Ingenieure können sich wieder mehr um Konstruktion und Fertigungsplanung von Neuprodukten und damit Innovation kümmern, statt Sachbearbeiteraufgaben zu übernehmen.

Apropos Sachbearbeiter: Unisono wurde bestätigt, dass Ingenieure viel zu sehr damit beschäftigt sind, Informationen aus Zeichnungen und Texten zu extrahieren, Daten von einem System ins andere zu übertragen und Konsistenzchecks in unterschiedlichen Systemen durchzuführen. Viele Gesprächspartner schätzten, dass sie deutlich unter 50 % ihrer Zeit für echte Engineering-Wertschöpfung verwenden – der Rest ist Suchen, Übertragen, Prüfen.

Folgende manuelle Tätigkeiten wurden am häufigsten in Gesprächen mit dem Engineering genannt:

• Sachnummern reduzieren:

  Bei vielen Unternehmen war nicht der gesamte Teilebestand in einer sauberen und einheitlichen Nomenklatur im PLM hinterlegt. Deshalb konnte der Gleichteilanteil auch nicht über PLM-Funktionalität erhöht werden. Zwar gab es manchmal Standardteilekataloge, aber daran wurde sich nicht durchgängig gehalten. Die Folge: Manuelles Durchsuchen des Teilebestands, um ähnliche Teile zu identifizieren und den Gleichteilanteil zu erhöhen. Das ist aufwändig und nicht nachhaltig.

  
  

• Ähnliche Teile finden:

  Oft ist den Konstrukteuren gar nicht bekannt, dass eine Kundenanforderung schon einmal umgesetzt wurde. Dann wird entweder ein erfahrener Kollege gefragt und die Suche geht los – oder es wird eine neue Sachnummer angelegt und schnell ein neues Teil konstruiert.

  
  

• Normen und Unternehmensrichtlinien lesen:

  Viele Unternehmen bedienen unterschiedliche Märkte mit unterschiedlichen Normen. Oder haben dedizierte Konstruktionsrichtlinien (z.B. Vorgaben im Bereich Schweißen) oder werkspezifische Fertigungsrichtlinien, um eine gute Herstellbarkeit sicherzustellen. Meist liegen die Dokumente in sehr umfangreichen PDFs irgendwo auf dem SharePoint.

  
  

• Zeichnungen prüfen:

  Nach wie vor spielen 2D-Zeichnungen eine wichtige Rolle. Oft werden 2D-Zeichnungen an Zulieferer ausgegeben, die dann (mehr oder weniger) strikt nach Zeichnungsvorgaben fertigen. Da Teile früher oft intern gefertigt wurden, war die Zeichnungsqualität mal gut und mal weniger gut. Daher investieren Konstrukteure viel Zeit, um Korrektheit und Vollständigkeit sicherzustellen.

  
  

• Konfigurationsregelwerke in Excel:

  Variantenkonfigurationen werden noch häufig in (manchmal sehr fragilen) Excel-Monstern erstellt. Die Ergebnisse müssen dann oft manuell in andere IT-Systeme übertragen werden. Spannenderweise berichteten das auch Unternehmen, die bereits ein CPQ im Einsatz hatten. Auch dort gelang die durchgängige Konfiguration der Konstruktions- und Fertigungsdokumente nicht E2E.

  
  

• Menschliche Schnittstellen:

  Der größte Schmerz besteht im manuellen Datenauslesen und -übertragen von einem IT-System, Excel-File mit Berechnungen oder Simulationswerkzeugen ins nächste. 

Im Industrial Engineering haben die meisten mit folgenden manuellen Tätigkeiten zu kämpfen:

• Referenzteile finden:

  Selten werden komplett neue Teile gefertigt. Meist wurden in der Vergangenheit bereits ähnliche Teile hergestellt. Aber die Suche nach diesen Referenzen im ERP oder anderen Systemen ist häufig sehr aufwändig.

  
  

• Konstruktionsunterlagen auf Vollständigkeit prüfen:

  Manchmal scheitert es daran, dass nicht alle notwendigen Fertigungstoleranzen von der Konstruktion vorgegeben wurden. Oder dass einzelne Vorgaben (oder Material) zu sehr aufwändigen Änderungen auf dem Shopfloor führen. Das führt zu (telefonischen) Abstimmungen zwischen Industrial Engineering / Arbeitsvorbereitung und Konstruktion.

  
  

• Werkzeuge auswählen:

  Das richtige Werkzeug für einen Bearbeitungsschritt zu finden, bedeutet oft: Werkzeugdatenbank (oder SharePoint) und Werkzeugdatenblatt (oder Herstellerkatalog) öffnen und händisch Anforderungen aus dem Bearbeitungsvorgang (z.B. Toleranzen beim Drehen) mit den Werkzeugeigenschaften abgleichen.

  
  

• Passende Maschine finden:

  Auch bei der Auswahl der geeigneten Maschine zeigt sich dasselbe Bild. Oft noch erschwert dadurch, dass Stammdaten im ERP nicht ganz korrekt sind und der Planer auf den Shopfloor gehen muss, um Anforderungen mit den Kollegen vor Ort zu besprechen. Das bedeutet Aufwand und kostet Durchlaufzeit.

  
  

• Arbeitsplan erstellen und Bearbeitungszeiten ermitteln:

  Letztlich münden (fast) alle Informationen in den Arbeitsplan. Meist wird ein Referenzarbeitsplan genutzt und nur einzelne Positionen angepasst. Das ist aufwändig und führt im Eifer des Gefechts oft zu Planungsfehlern, die am Shopfloor Rückfragen, Nacharbeit oder aufwändige Anpassungen im Prozess auslösen. Wenige Unternehmen spielen die tatsächlichen Bearbeitungszeiten (aus dem MES) in die Planung zurück.

  
  

• Montagereihenfolge bestimmen:

  Auch bei der Montageplanung sehen wir ein ähnliches Bild: Montagevorranggraphen werden händisch (erfahrungsbasiert) erstellt, die MBOM nicht automatisiert aus der EBOM abgeleitet, Montagereihenfolgen und die Zuordnung zu Arbeitsplätzen manuell in Excel geplant.

  
  

• Herstellkosten kalkulieren:

  Oft werden Herstellkosten für Angebote noch in riesigen Excel-Tabellen kalkuliert. Die wollen mit Daten gefüttert werden – und die kommen selten über automatisierte Schnittstellen aus dem ERP oder anderen Systemen in die Kalkulationsvorlagen.

Wie Sie sehen, sind das alles recht greifbare Herausforderungen. Es geht also noch gar nicht so sehr um fancy KI-Visionen, in denen beispielsweise Agenten selbständig 3D-Modelle auf Basis natürlicher Sprache erstellen. Ich will damit nicht sagen, dass KI nicht in der Lage ist oder sein wird, auch solche fortgeschrittenen Herausforderungen zu lösen. Aber ich glaube, den meisten Unternehmen ist schon geholfen, wenn sie eine robuste, sichere Lösung für die oben genannten Themen hätten. Kurzer Spoiler: Ich bin guter Dinge, dass wir das hinbekommen.

III. Was bedeutet das für Sie als CEO, CTO oder COO oder Head of Engineering / Industrial Engineering? Zum Beispiel mindestens 40 Prozent verschenkte Durchlaufzeit. Und damit Umsatz. Und Kosten. Und EBIT.

Nach den Gesprächen gehe ich davon aus, dass der durchschnittliche Automatisierungsgrad bei diesen Unternehmen unter 20 % liegt. Aus eigener Projekterfahrung weiß ich, dass ein Automatisierungsgrad von 80 % machbar ist. Was bedeutet das für die Durchlaufzeit, wenn man den Automatisierungsgrad um 60 Prozentpunkte erhöht? Die der Produktion vorgelagerten Bereiche sind im Maschinen- und Anlagenbau typischerweise für ca. 70 % der Gesamtdurchlaufzeit von der Kundenbestellung bis zur Zustellung verantwortlich. Das bedeutet, dass bis zu 40 % Durchlaufzeitreduktion möglich sind. Hört man sich in der Branche um, dann sind zu lange Durchlaufzeiten mittlerweile eine der größten Herausforderungen, die die deutsche Industrie im Vergleich zum internationalen Wettbewerb hat. Denn wer schneller liefert, kann auch mehr verkaufen. Wer pro verkaufter Maschine weniger manuelle Arbeit hat, hat weniger Kosten und letztlich ein höheres EBIT.

Manche befragten Fachbereichsleiter äußerten die Sorge, dass sich diese Potenziale nur heben lassen, wenn man abteilungsübergreifend automatisiert – und bei wenigen CEOs der Branche wäre ein durchgängiger Variantenentstehungsprozess oberste Priorität. Nach vielen Gesprächen unter anderem auf Branchentreffen, bin ich aber überzeugt, dass sich da gerade etwas ändert und diese Herausforderungen verstärkt in den Fokus der Unternehmensleitungen rücken.

 IV. Die zugrundeliegenden Ursachen? Hochfragmentierte Engineering-Toollandschaften und Regelwerke, die nicht operativ in Prozessen verankert sind

Dass die Welt im technischen Büro anders aussieht als im kaufmännischen, war uns nach Jahrzehnten in der Branche klar. Aber wie heterogen die Toollandschaft dann teilweise ist, hat uns doch überrascht: Einzelne Unternehmen berichteten, dass sie alleine in der Produktionsplanung 150 (!) unterschiedliche Softwaresysteme, Berechnungstools etc. im Einsatz haben. Vieles von unterschiedlichen Herstellern. Kaum eines integriert. Meist bedient durch teure Ingenieure. Bedenkt man, dass an der Variantenentstehung „daneben“ noch CRM, CPQ, PLM, CAx und MES beteiligt sind, wird das Ausmaß dieser manuellen Arbeit deutlich.

Viele Maschinenbauunternehmen haben in den letzten Jahren und Jahrzehnten viel Aufwand in die Themen Modularisierung, Baukasten, Standardisierung und Konfiguration investiert. Das ist gut, weil das die Basis für KI-Automatisierung ist. Aber das Problem, das viele haben: Bisher existieren diese Regelwerke in einzelnen Softwaresystemen oder in Text- oder Excel-Files. Wenige schaffen es wirklich, durchgängig über alle Systeme Varianten automatisiert abzuleiten.

 V. Warte mal. Gibt’s dafür nicht eigentlich Product Lifecycle Management Systeme und Suiten mit zig ergänzenden Produkten? Mag sein, aber nur 4 von 20 nutzen sie und sind zufrieden!

Manchmal haben wir (vor allem aus der IT) gehört: Problem erkannt, wir führen in den nächsten Jahren ein PLM ein und machen eine PLM-ERP-Integration. Dann ist das Problem gelöst. Ich muss leider sagen: In der Mehrheit der Fälle wird das so nicht eintreten. Warum nicht?

Wenn man der Theorie folgt, müsste doch genau hier die Lösung liegen. Durchgängige Datenmodelle. End-to-End-Prozesse. Nahtlose Integration von Konfiguration, Konstruktion, Fertigungsplanung und Shopfloor. So zumindest das Versprechen. Die Realität aus unseren Gesprächen sieht deutlich anders aus.

Von 20 befragten Unternehmen gaben lediglich 4 Unternehmen an, ihr PLM wirklich umfassend und abteilungsübergreifend zu nutzen. Alle anderen 16 befanden sich in einer der folgenden Situationen:

• Entweder sie hatten noch kein PLM.

• Oder sie planten eine Einführung.

• Oder sie hatten eines – waren aber unzufrieden und nutzten es faktisch eher als PDM-System.

Schauen wir uns zunächst die vier Unternehmen an, die PLM wirklich breit im Einsatz haben. Diese Unternehmen hatten ihre Produktlandschaft im Wesentlichen in zwei Kategorien strukturiert:

1. Standardprodukte, nahezu vollständig konfigurierbar

2. Sonderprodukte, stark kundenindividuell geprägt, Teile aber trotzdem konfigurierbar

Im Standardgeschäft war Beeindruckendes gelungen. Dort konnten sie vom Produktkonfigurator über Stückliste und Arbeitsplan bis hin zum Maschinenprogramm auf dem Shopfloor weitgehend durchgängig automatisieren. Varianten wurden regelbasiert abgeleitet, Dokumente automatisch erzeugt, NC-Programme generiert. Genau so stellt man sich das vor.

Aber: Das ist nur die halbe Wahrheit. Denn um dort hinzukommen, waren enorme Anstrengungen nötig. Denn in der Praxis erleben viele Unternehmen PLM trotzdem als engineering-zentriert. Die anderen Softwaresysteme kamen von anderen Herstellern und mussten über sehr aufwändige Softwareindividualentwicklungsprojekte integriert werden. Das kostete viel Zeit und war teuer.

Sobald es in Richtung Sonderprodukte ging, zeigte sich trotz sehr weitreichender PLM-Nutzung ein weiterhin hoher manueller Anteil. Warum? Weil die Komplexität höher und die Wiederholhäufigkeit niedriger ist als bei Standardprodukten. Da stößt Softwareindividualentwicklung an wirtschaftliche Grenzen.

Wichtiges Fazit: Selbst bei sehr weitreichender PLM-Nutzung bleibt ein erheblicher Automatisierungsbedarf bestehen. PLM ist kein Allheilmittel für E2E-Automatisierung.

Und die anderen 16 Unternehmen? Hier zeigte sich das Problem in seiner vollen Tragweite. Manche Unternehmen berichteten, dass sie seit Jahren (!) an der Einführung eines PLM arbeiten. Lizenzen werden bereits bezahlt. Produktiv genutzt wird das System noch nicht. Man rechnet mit weiteren Monaten Implementierungsdauer. Und schon jetzt ist man sich intern sicher, dass das System bei weitem nicht die Automatisierung bringen wird, die man sich ursprünglich erhofft hatte.

Andere Unternehmen schilderten ein anderes Phänomen: Bei größeren PLM-Updates fühlt sich jedes Release wie ein neues Einführungsprojekt an. Warum? Weil 20–30 % des Systems gecustomized sind. Jede neue Version muss wieder angepasst, getestet und integriert werden. Das bindet Ressourcen und lähmt die Organisation. Einige Unternehmen planen aktuell überhaupt kein PLM. Oder schieben das Thema bewusst in eine ferne Zukunft.

Und besonders interessant:

In unserer Stichprobe plant kein Unternehmen, alles über Bord zu werfen und auf eine einzige Suite zu standardisieren.

Warum?

Weil über Jahre enorm viel Fachwissen in bestehende Tools geflossen ist. Weil einzelne Aufgabenstellungen heute von spezialisierten Softwarelösungen oder Startups deutlich besser gelöst werden als von generischen PLM-Suiten. Um den Text nicht noch länger werden zu lassen, möchte ich an der Stelle gar nicht viel zu den in letzter Zeit häufig diskutierten technologischen Schwierigkeiten der PLM-Systeme sagen (Stichworte: monolithische Systeme, Technologie aus den 90ern, relationale Datenbanken mit viel Prozesswissen). Hier verweise ich auf die von mir sehr geschätzten Beiträge von beyondplm.com.

Was heißt das unterm Strich?

PLM kann eine wichtige Grundlage sein. Aber PLM allein führt nicht automatisch zu durchgängiger Variantenautomatisierung.

 VI. Sind Workflowautomatisierungsplattformen wie n8n oder RPA-Plattformen wie UiPath die Lösung? Nicht wirklich.

Vier der Unternehmen (spannenderweise andere als die vier, die weit mit der PLM-Nutzung waren) haben, hauptsächlich getrieben aus der IT, erste Versuche unternommen, einzelne Prozessschritte mit n8n, UiPath oder Power Automate zu automatisieren. Allerdings mit überschaubarem Erfolg. Was waren die Erkenntnisse?

1. Schnittstellenbibliotheken
   Den eigentlichen Vorteil, den Plattformen wie n8n sonst in vielen Kontexten haben, konnten sie im Engineering / Industrial Engineering nicht ausspielen: Out-of-the-box fehlten ihnen die domänenspezifischen Schnittstellen und Datenmodelle zu CAx-/PLM-/Simulationslösungen.

   
   

2. Vorlagen
   Sämtliche Automatisierungen mussten händisch modelliert werden. Es gab keine Vorlagen für beispielsweise Gleichteilanalyse, Arbeitsplanerstellung oder Herstellkostenskalkulation.

   
   

3. KI-Services
   Wiederkehrende Aufgaben, wie etwa ähnliche CAD-Modelle zu finden, waren praktisch nicht sinnvoll automatisierbar, weil Engineering-spezifische KI-Bausteine und vor allem der Kontext fehlten (Datenmodell, Semantik, Stücklisten-/CAD-Bezug).

   
   

4. Governance
   So flexibel (und zugegebenermaßen cool) diese Plattformen auch sind, umso größer ist die Gefahr von Wildwuchs. Wenn jeder Ingenieur anfängt, seine Aufgaben zu automatisieren, und es keine Schicht darüber gibt, die das in einen robusten, wartbaren und kontrollierbaren Prozess überführt, droht die Variantenentstehung aus dem Ruder zu laufen. Beim wichtigsten Geschäftsprozess eines Maschinenbauers möchte das keiner. Denn was ist im Maschinenbau wichtiger, als Produkte zu entwickeln und zu produzieren?

   
   

5. Security
   Wer alle seine IT-Systeme über eine Plattform vernetzt, erwartet zu Recht allerhöchste Security-Standards.

   
   

6. Halluzination
   Das war ein Phänomen, das sich erst nach etlichen Automatisierungen und einem höheren Reifegrad gezeigt hat. Denn viele Aufgaben in dem Umfeld sind noch ohne tiefgreifende Intelligenz automatisierbar. Bei höherem Schwierigkeitsgrad zeigte sich: Ohne sauberen Kontext, Regeln und Absicherung fangen LLMs an zu halluzinieren – und die Ergebnisqualität wird unzuverlässig. Eines der befragten Unternehmen beschäftigt sich damit folgerichtig mit dem Konzept des Knowledge Graphen, der Produkt- und Prozessdaten aus unterschiedlichen Quellen zusammenführt und LLMs in maschinenlesbarer Form zur Verfügung stellt.

Zwischenfazit:

Ich halte Workflowautomatisierung für den vielversprechendsten Ansatz – wenn man es schafft, die genannten Limitationen zu lösen.

 VII. Was ist denn jetzt mit KI? Wie wird das bisher genutzt? Bei den befragten Unternehmen bisher noch gar nicht. Zumindest nicht fest in die Prozesse integriert. Aber: Das wird (und muss) sich ändern.

Eines vorweg: Ich bin kein KI-Apostel. Mir geht es nicht darum, eine Technologie zu nehmen und zu schauen, ob es dafür ein Problem gibt. Aber wir selbst nutzen KI ständig bei wailand und ich sehe, zu welchen Veränderungen sie in vielen Bereichen schon geführt hat (man denke nur an die Softwareentwicklung). Ich bin überzeugt: KI wird Engineering und Industrial Engineering radikal verändern – und die ersten Effekte sieht man bereits heute im Alltag der Konstrukteure und Planer. Wenn wir mit Konstrukteuren oder Produktionsplanern gesprochen haben, hat nahezu jeder berichtet, dass er heute schon LLMs für seine Arbeit nutzt. Allerdings mit privaten Accounts und per Copy-Paste im Chatfenster. Dass das nicht die Zukunft sein kann (Security, IP?), dürfte jedem klar sein. Aber ohne geht es eben auch nicht. Wie soll die europäische Industrie sonst mit den asiatischen Wettbewerbern mithalten?

Was aus meiner Sicht nicht zum Ziel führt (und Schande über mein Haupt, ich habe früher selbst viele dieser Projekte gemacht):

Monatelange Strategieprojekte und Ideation-Workshops, um anschließend einzelne, fancy KI-Services zu bauen. Das ist zu langsam und ich habe ehrlich gesagt selten erlebt, dass so wirklich Bahnbrechendes entstanden ist.

Wie dann?

Natürlich braucht es Top-Management-Commitment und Budget, um konsequent automatisieren zu können. Aber dafür braucht es keine monate- oder jahrelangen Beratungsprojekte. Aus meiner Sicht machen die vier Unternehmen, die mit Workflowautomatisierungsplattformen gestartet sind, vieles richtig: Loslegen, erste Prozesse automatisieren, dabei lernen, Limitationen erleben und dafür Lösungen finden. Ich bin mir sicher, dass diese Unternehmen in einigen Jahren deutlich erfolgreicher sein werden als die, die jetzt erst ewiglange KI-Strategieprojekte machen.

VIII. Welche Anforderungen sollte ich als CEO, CTO oder COO an eine Automatisierungslösung im Engineering / Industrial Engineering stellen?

Nach all den Gesprächen stellt sich zwangsläufig die Frage: Wenn PLM und generische Workflowautomatisierungsplattformen allein es nicht richten – worauf sollte ich als Entscheider achten? Was muss eine Lösung leisten, damit sie nicht nur ein weiteres Tool in einer ohnehin überfrachteten Landschaft wird? Ich würde es auf sechs zentrale Anforderungen herunterbrechen.

1. UI/UX radikal aus Sicht von Ingenieuren gedacht

Das mag banal klingen, ist es aber nicht. Wenn Ingenieure eine Plattform nicht gerne nutzen, wird sie sich nicht durchsetzen. Punkt. Dann entstehen wieder Excel-Schattenlösungen. Oder man kehrt zu manuellen Workarounds zurück. Eine Automatisierungslösung muss so gestaltet sein, dass sie:

• fachliche Logiken intuitiv abbildet

• ohne Programmierkenntnisse automatisierbar ist

• schnell Ergebnisse liefert

• und sich in den Arbeitsalltag integriert, statt ihn zu verkomplizieren

Engineering ist kein IT-Projekt. Wer hier erfolgreich sein will, muss Werkzeuge bauen, die sich an Konstrukteure und Industrial Engineers richten – nicht an Techies.

2. KI allein reicht nicht – deterministische Regelwerke sind Pflicht

LLMs und KI-Agenten sind mächtig. Keine Frage. Aber im Engineering geht es nicht nur um Wahrscheinlichkeiten. Es geht um Toleranzen, Sicherheitsanforderungen, Normkonformität und Fertigungsgrenzen. Das bedeutet: Neben KI braucht es saubere, deterministische Regelwerke. KI kann unterstützen, interpretieren, Vorschläge machen. Aber robuste E2E-Automatisierung entsteht nur, wenn probabilistische KI-Modelle mit harten, deterministischen Regeln zusammenspielen.

3. Starke Governance statt Wildwuchs

Viele Unternehmen haben in den letzten Jahren erlebt, was passiert, wenn Automatisierung unkoordiniert entsteht: Excel-Monster, lokale Skripte, intransparente Logiken. Wer ernsthaft automatisieren will, braucht:

• klare Freigabemechanismen

• Rollen- und Rechtekonzepte

• Transparenz über Abhängigkeiten

• Nachvollziehbarkeit von Entscheidungen

Ohne Governance entsteht kein skalierbares System – sondern ein Flickenteppich.

4. Security auf Enterprise-Niveau

Wer das Engineering automatisiert, greift auf das sensibelste Wissen des Unternehmens zu:

• Produktarchitekturen

• Kalkulationslogiken

• Fertigungsprozesse

• Maschinenprogramme

• kundenspezifische Lösungen

Das sind die „Kronjuwelen“ jedes Maschinenbauers. Dementsprechend müssen Security-Standards hoch sein. Zugriffskontrolle, Verschlüsselung, Mandantenfähigkeit, Audit-Trails – das alles ist kein Nice-to-have, sondern Grundvoraussetzung.

5. Cloud oder On-Prem? Die Realität ist geteilt.

Ein Teil der Unternehmen möchte Engineering-Daten und -Systeme nach wie vor ausschließlich auf eigener Infrastruktur betreiben. Gleichzeitig gibt es eine wachsende Gruppe mit klarer Cloud-first-Strategie. Diese Unternehmen sind bereit, auch sensible Engineering-Daten in die Cloud zu bringen – wenn Security und Compliance stimmen. Eine zukunftsfähige Lösung muss beide Welten unterstützen.

6. Der Knowledge Graph als Rückgrat

Eine der zentralen Komponenten kann ein Knowledge Graph sein – weil er Produkt- und Prozesswissen so zusammenführt, dass KI und Regeln wirklich belastbar darauf arbeiten können und folgende Zusammenhänge maschinenlesbar macht:

• Beziehungen zwischen Bauteilen

• Abhängigkeiten von Konfigurationsregeln

• Verknüpfungen zwischen EBOM, MBOM und Arbeitsplänen

• Zuordnung zu Maschinen, Werkzeugen und Ressourcen

• Normen und Richtlinien im Kontext konkreter Produktstrukturen

Erst wenn dieses Wissen strukturiert, semantisch verknüpft und maschinenlesbar vorliegt, kann KI ihr volles Potenzial entfalten und Variantenentstehung E2E automatisieren.

Was wir bei wailand konkret tun – und wo wir stehen

Ich bin Patrick Kübler, einer der Gründer von wailand. Ich war mit 14 zum ersten Mal in den Ferien als Hilfsarbeiter in einer Fabrik und bin seitdem in der verarbeitenden Industrie unterwegs.

Natürlich beschäftigen wir uns bei wailand nicht nur theoretisch mit diesen Fragestellungen. Im Kern unserer Plattform steht eine Workflowautomatisierungsengine, die auf die beschriebenen Anforderungen im Engineering und Industrial Engineering ausgelegt ist. Erste Schnittstellen in typische Engineering- und ERP-Umgebungen sind gebaut. Zentrale Security- und Governance-Mechanismen sind implementiert. Als erster Service ist eine CAD-Ähnlichkeitsanalyse produktiv verfügbar.

Wir arbeiten mit Kunden an konkreten Prozessautomatisierungen im Variantenentstehungsprozess. Schritt für Schritt. Und immer mit dem Anspruch, robuste E2E-Automatisierung zu schaffen – nicht nur einzelne Leuchtturm-Use-Cases. Aber wir sind noch lange nicht fertig. Und genau deshalb sind wir kontinuierlich auf der Suche nach neuen, anspruchsvollen Herausforderungen bei Kunden, die Engineering und Industrial Engineering ernsthaft automatisieren wollen.