Drei Monitore und ein Problem: Links die technische Zeichnung, in der Mitte eine Excel mit Taktzeiten, Arbeitsplätzen und Werkzeugen, rechts ein Simulationstool, das die Montage und den Materialfluss simuliert. Und dazwischen – ich, der Ingenieur, der Informationen von A nach B schiebt, statt zu planen.

Jahrelang habe ich als Maschinenbauingenieur Montagesysteme geplant: konkrete Produktvarianten eingeplant, um möglichst wenig Wartezeiten bei den Monteuren entstehen zu lassen, Maschinenbelegungen optimiert, um Rüstzeiten zu reduzieren, und Fabriken um- und neu geplant. Und ich habe erlebt, wie viel meiner (Ingenieurs-)Zeit dabei für Sachbearbeiterarbeit verloren geht.

In diesem Beitrag zeige ich, welche Teile des Industrial Engineerings heute realistisch automatisierbar sind – und wo KI ohne saubere Daten und Governance doch an Grenzen stößt (Spoiler: Später als die meisten erwarten würden).

Aus Projekten mit Kunden aus dem Maschinen- und Anlagenbau und aus Gesprächen mit über 20 Unternehmen in den letzten Wochen ist mir ein wiederkehrendes Muster begegnet (lesen Sie hierzu meinen Blog-Beitrag mit den wichtigsten Erkenntnissen: https://www.wailand.io/blog/20-interviews-in-6-wochen): Der Engpass liegt oft nicht auf dem Shopfloor, sondern davor – unter anderem im Industrial Engineering, der Arbeitsvorbereitung sowie der Fertigungs- und Montageplanung. Wenn hier Mitarbeitende nicht mehr hinterherkommen, bleiben Kundenaufträge liegen – mit unzufriedenen Kunden und im schlimmsten Fall gefährdeten Umsätzen. Aber warum ist das so?

I. Warum Industrial Engineering zum Engpass wird

Ich bin ein Freund davon, zuerst das Problem sauber zu beschreiben und erst dann die passende Lösung auszuwählen (und nicht: „Lasst uns Workshops machen und herausfinden, wo man KI einsetzen kann.“). Deshalb ist es wichtig, zwei Bereiche klar zu unterscheiden: Was ist grundsätzlich ableitbar, weil Regeln und Parameter existieren – und was ist tatsächlich neu, weil Kundenanforderungen, Geometrie oder Prozessanforderungen (bisher) nicht im Regelwerk abgebildet sind?

1) Fall 1: Konfigurierbar, aber nicht durchautomatisiert

Im Maschinenbau gilt selbst bei Sondermaschinen häufig: Der konfigurierbare (oder zumindest aus bestehenden Modulen kombinierbare) Anteil einer Kundenvariante ist größer als der Teil, der tatsächlich neu konstruiert oder wesentlich angepasst werden muss. Die genaue Verteilung schwankt natürlich nach Produkt, Reifegrad des Baukastens und Kundenanforderung – entscheidend ist die Tendenz: Der größere Teil ist inhaltlich „bekannt“, wird aber nicht automatisch bis in die Fertigungs- und Montageplanung hinein genutzt.

Was dann passiert, ist paradox: Obwohl die Variante weitgehend festgelegt ist, endet die Automatisierung im CPQ oder in einem „Excel-Monster“. Arbeitspläne, Montageunterlagen und Prüfplanung entstehen danach erneut – häufig durch Copy/Paste aus Referenzen plus manuelle Anpassungen. Der Prozess ist nicht deshalb manuell, weil er es technisch sein müsste, sondern weil Systemgrenzen (CPQ/PLM/ERP/MES), fehlende Datenstandards und fehlende Versionierung die Durchgängigkeit unterbrechen. Wenn beispielsweise ein Arbeitsplan-Template überarbeitet wurde, aber nicht eindeutig nachvollziehbar ist, ob für einen konkreten Auftrag die alte oder die neue Version gilt, kann keine Automatik sicher ableiten – und der Planer greift wieder manuell ein.

2) Fall 2: Kein Regelwerk – aber dennoch wiederverwendbar

Der nicht vollständig konfigurierbare Anteil wird oft als „nicht automatisierbar“ abgetan. Das ist zu grob. Zwar fehlen für echte Neuanteile Regeln – aber es gibt fast immer historisches Wissen: ähnliche Bauteile, ähnliche Kundenanforderungen, frühere Arbeitspläne, Rückmeldedaten aus der Fertigung, bewährte Prüfmerkmale. Das Problem ist selten „kein Wissen“, sondern „Wissen nicht auffindbar“: Daten liegen verteilt in ERP, PLM, CAD-Archiven, Dateisystemen und Köpfen.

Automatisierung in diesem zweiten Bereich bedeutet daher nicht „Regelwerk anwenden“, sondern: relevante Referenzen zuverlässig finden, Unterschiede sichtbar machen und daraus einen belastbaren Erstentwurf ableiten, der anschließend von Fachleuten validiert wird. Hier hilft zum Beispiel eine CAD-Ähnlichkeitsanalyse, die Referenzteile zuverlässig findet – anfangs mittels geometrischer Ähnlichkeit, später erweitert um weitere Merkmale wie Werkstoff und Toleranzen oder durch eine Ähnlichkeitssuche auf Basis von Kundenanforderungen bzw. Produktmerkmalen.

3) Wo die Ingenieurszeit wirklich bleibt

In beiden Fällen beobachte ich häufig folgende Ingenieursarbeiten, die nicht direkt wertschöpfend sind:

• Unterlagen prüfen und Vollständigkeit herstellen (häufig mit Medienbrüchen zwischen CAD, PLM, ERP, E-Mail, Dateien).

  
  

• Referenzen suchen: ähnliche Teile, frühere Aufträge, alte Arbeitspläne, passende Betriebsmittel – oft über gewachsene Benennungslogiken in Teilenummern oder persönliche Erfahrung.

  
  

• Werksstandards berücksichtigen: Normen, Prozessvorgaben, Prüfanforderungen, zulässige Maschinen/Werkzeuge – häufig als PDF/Word/Confluence, selten maschinenlesbar.

  
  

• Maschinen, Werkzeuge und Prozesse auswählen: nicht nur „was geht grundsätzlich“, sondern „was geht bei uns“ (Maschinenpark, Verfügbarkeit, Qualitätsfähigkeit, Stückzahl).

  
  

• Arbeitspläne, Montagefolge und Prüfunterlagen erstellen, freigeben und ins ERP/MES überführen.

Der Kern: Ein großer Teil der Zeit geht nicht in fachliche Entscheidung, sondern in Informationssuche, Abgleich und Dokumentenarbeit. Das ist besonders schmerzhaft, weil die wertschöpfende Ingenieursarbeit – Prozesswahl, Risikoabschätzung, Optimierung – dadurch in die letzte Minute rutscht.

II. Warum bisherige Ansätze zu kurz greifen

1) PLM: verwaltet Konstruktionsdaten, aber die letzte Meile bleibt offen

PLM-Systeme decken heute vor allem Konstruktionsdaten ab: CAD, Zeichnungen, EBOM, Änderungen. In der Praxis endet die Durchgängigkeit jedoch genau dort: Die Fertigungslogik (MBOM, Arbeitspläne, Betriebsmittel, Zeiten, Prüfplanung) bleibt organisatorisch und systemisch verteilt – teils im ERP, teils im MES, teils in Spezialtools und Excel. Dann hilft auch ein PLM nur begrenzt, weil die eigentliche Planungsarbeit weiterhin über Medienbrüche läuft.

2) Individualintegration: teuer von Anfang an und eine Dauerbaustelle

Individuelle Schnittstellen zwischen PLM/ERP/MES und Engineering-Tools können einzelne Lücken schließen. Aber schon das initiale Projekt ist aufwändig: Die meisten Softwareentwickler und IT-Consultants bringen wenig Erfahrung in der komplexen Industrial-Engineering-Welt mit. Bevor die erste Zeile Code geschrieben wird, müssen sie die fachlichen Zusammenhänge verstehen – das kostet Zeit und Geld, und der Kunde zahlt die Einarbeitung mit. Danach wird es nicht einfacher: Datenmodelle ändern sich, Prozesse verändern sich, Systeme werden upgegradet. So wird Integration zur Dauerbaustelle.

3) Regelwerke: stark – mit zwei strukturellen Grenzen

Regelwerke sind eine wichtige Grundlage. Zwei Herausforderungen bleiben: (a) Regelwerke enden häufig am Konfigurator und werden nicht bis in Arbeitsplan, Montage und Prüfplanung „durchdekliniert“. (b) Regelwerke veralten und benötigen Pflege. Und für echte Neuanteile helfen Regeln per Definition nicht – dort braucht es Referenzwissen und datengetriebene Vorschläge.

Das beobachte nicht nur ich: Wenn Studien und Praxisberichte KI im Engineering diskutieren, taucht daher immer wieder dieselbe Ursache auf: verteilte Daten, fehlende Interoperabilität und fehlende Durchgängigkeit (hier verweise ich gerne auf das gemeinsame Whitepaper von Accenture, DFKI und Fraunhofer ISST „AI in New Product Development“ aus 2025).

III. Was heute realistisch möglich ist

1) Den konfigurierbaren Anteil durchgängig ableiten

Wenn eine Variante überwiegend konfigurierbar ist, sollte das Ergebnis nicht als „Dokument“ enden, sondern als strukturierte Fertigungs- und Montageinformation weiterfließen: MBOM, Arbeitsplan-Struktur, Standardoperationen, Variantenparameter, Prüfmerkmale. Ziel ist nicht, den Planer zu ersetzen, sondern den Fokus von der Neuerstellung zur Validierung von generierten Vorschlägen zu verschieben: Die Plattform erzeugt automatisiert einen konsistenten Erstentwurf – der Arbeitsvorbereiter prüft Ausnahmen und gibt frei.

Praktisch bedeutet das: Eine Integrationsschicht, die CPQ/PLM/ERP/MES verbindet, plus ein Modell, das Regeln und Parameter in konkrete Arbeitspläne, Montagefolgen und Prüfunterlagen übersetzt. Entscheidend ist Versionierung (welche Regel gilt für welchen Stand?) und Nachvollziehbarkeit (warum wurde diese Operation/Variante gewählt?).

2) Den kundenindividuellen Anteil unterstützen

Für echte Neuanteile ist 100 % Automatisierung die falsche Erwartung. Realistisch ist: Die Plattform findet belastbare Referenzen, macht Unterschiede explizit und schlägt einen Erstentwurf vor. Das ist ein Produktivitätshebel, weil der Planer nicht bei Null beginnt.

Eine robuste Referenzsuche muss mehrere Dimensionen kombinieren:

• Geometrie: 3D-Modelle lassen sich so aufbereiten, dass ähnliche Formen automatisch auffindbar werden (sog. Form-Embeddings, also numerische Repräsentationen der Geometrie) – typischerweise nach geeigneter Normalisierung unabhängig von Lage und Skalierung sowie weitgehend unabhängig vom Datenformat (z. B. B-Rep, also Flächenmodelle, oder Mesh, also Dreiecksnetze).

  
  

• Semantik: Form allein reicht nicht. Material, Toleranzklasse, Oberfläche, Sicherheitsanforderungen oder Stückzahl können die Prozesswahl stark beeinflussen.

  
  

• Auftragshistorie: Ähnliche Projekte liefern nicht nur Teile, sondern auch bewährte Arbeitspläne, Prüfmerkmale, Lieferanten- und Betriebsmittelentscheidungen.

Der Mehrwert entsteht in der Kombination: „Ähnliches Teil“ + „ähnliche Anforderungen“ + „ähnliche Rahmenbedingungen“.

3) Gemeinsamer Baustein: Von Produktmerkmalen zu Fertigungslogik

Für beide Szenarien braucht es eine Übersetzung von Kundenanforderungen und Produktmerkmalen in fertigungsrelevante Merkmale (z.B. Bohrungen, Passungen, Toleranzklassen, Oberflächen, Materialien, Schweißnähte, Montagemerkmale, Prüfmerkmale). Daraus kann man Prozesskandidaten ableiten – aber nicht als harte „Wenn-dann“-Automatik ohne Kontext.

Beispiel: Eine Passung H7 ist ein starkes Signal, dass eine Feinbearbeitung (z.B. Reiben, Honen, Feinschleifen, Feinbohren) wahrscheinlich wird. Welches Fertigungsverfahren sinnvoll ist, hängt von Durchmesser, Werkstoff, Vorprozess, Losgröße, Qualitätsanforderung und dem verfügbaren Maschinenpark ab. Eine gute Plattform bildet diese Entscheidung als Logik mit Parametern und Einschränkungen ab – und liefert Begründungen statt vorgespielter KI-Gewissheit.

Für Vorgabezeiten ist die Nutzung von Rückmeldedaten grundsätzlich vielversprechend – aber nur, wenn Daten sauber segmentiert werden (Rüsten/Bearbeiten/Störung), Ausreißer behandelt werden und Kontextmerkmale (Maschine, Material, Losgröße, Werkzeugzustand) berücksichtigt werden. Sonst entsteht nicht „Präzision“, sondern nur eine trügerische Scheingenauigkeit.

4) Werksstandards für KI nutzbar machen

Viele Werke haben umfangreiche Richtlinien: Prozessfreigaben, Prüfvorschriften, Vorgaben zur Oberflächenbehandlung oder Freigabelisten für Fertigungsverfahren und Maschinen. Damit KI diese Richtlinien nutzen kann, kommt sogenanntes RAG (also Retrieval-Augmented Generation – die KI durchsucht die vorhandenen Dokumente und stützt ihre Antworten auf die Inhalte) zum Einsatz. Drei Bedingungen müssen dafür erfüllt sein: (1) Dokumente sind versioniert und eindeutig referenzierbar, (2) jeder KI-Vorschlag muss die konkrete Quelle mitliefern – also welches Dokument, welche Version, welche Stelle – damit der Ingenieur nachprüfen kann, statt blind zu vertrauen, (3) es gibt Freigaberegeln, die verhindern, dass Vorschläge ungeprüft in ERP/MES landen.

Unter diesen Bedingungen kann RAG einen echten Mehrwert liefern: Der Ingenieur muss sich nicht mehr durch Ordnerstrukturen und PDF-Sammlungen arbeiten, sondern bekommt die relevante Norm oder Vorgabe mit belastbarem Verweis direkt zum Arbeitskontext geliefert.

IV. Was in der Praxis bremst

1) Datenqualität ist kein Grund zu warten

Datenqualität wird oft als Argument angeführt, warum KI-basierte Automatisierung „bei uns noch nicht geht“. Ich kenne das – auch ich habe Automatisierungen erlebt, bei denen erst die Datenqualität verbessert werden musste. Das kommt vor. Aber in der Praxis begegnet mir dazu häufig ein gefährliches Narrativ: „Wir müssen erst aufräumen, bevor wir mit KI anfangen können.“ Was dann passiert, sind jahrelange Stammdatenprojekte ohne konkretes Problembewusstsein – und am Ende kommt dabei selten etwas heraus, das Automatisierung wirklich ermöglicht.

Die Realität ist: Für viele Prozessautomatisierungen sind die vorhandenen Daten bereits gut genug. Der pragmatische Weg ist, dort zu starten, wo es heute schon geht – und Datenqualitätsprobleme dann zu lösen, wenn sie konkret auftreten, nicht wenn man sich vorstellt, dass sie irgendwann vielleicht mal auftreten könnten. Wer wartet, bis alles perfekt ist, wird von denen überholt, die mit dem Vorhandenen anfangen. Das heißt nicht, dass man jede Lösung für die Datenprobleme einzeln zusammenbastelt. Wenn sich aus den ersten Automatisierungen zeigt, dass z.B. strukturell eine Datenplattform fehlt, dann baut man sie mit einer sauberen Architektur auf – aber mit konkreten Use Cases aus echten Projekten, nicht mit künstlich erbrainstormten „Data Use Cases“.

Ein guter Startpunkt sind oft historische Arbeits- und Montagepläne: Sie wurden so gefertigt, also ist belegt, dass sie funktionieren. Daraus lassen sich Schritt für Schritt bessere Vorschläge, bessere Zeitmodelle und bessere Regelwerke ableiten.

2) Knowledge Graph: das Rückgrat für Suche und Nachvollziehbarkeit

Wenn Produktdaten, Fertigungswissen und Werksstandards in unterschiedlichen Systemen liegen, fehlt eine gemeinsame Sprache, die alles verbindet. Genau das leistet ein Knowledge Graph (also ein Wissensnetz, das Objekte und ihre Beziehungen zueinander explizit abbildet) – und damit Suche, Begründbarkeit und Validierung ermöglicht.

Konkret bedeutet das: Der Graph kennt die relevanten Objekte – Teile, Fertigungsmerkmale, Operationen, Maschinen, Werkzeuge, Werksnormen, Messmerkmale – und weiß, wie sie zusammenhängen: welches Merkmal welche Operation erfordert, welche Maschine für welchen Werkstoff freigegeben ist, welches Fertigungsverfahren sich bei ähnlichen Teilen bewährt hat.

Drei Dinge werden damit möglich, die ohne Graph schwer umsetzbar sind:

1. Regeln und Plausibilitätsprüfungen. Zum Beispiel: „Operation X ist für Werkstoff Y nicht freigegeben“ – solche Checks laufen automatisch, bevor ein Arbeitsplan zur Freigabe geht.

   
   

2. Erklärbare KI-Vorschläge. Wenn die Plattform einen Arbeitsplan vorschlägt, kann sie begründen, warum: „Ähnliche Welle mit h6 und 1m Länge wurde auf diesem Bearbeitungszentrum bereits gedreht.“ Der Ingenieur sieht nicht nur das Ergebnis, sondern den Weg dorthin.

   
   

3. Schutz vor KI-Halluzinationen. Weil Vorschläge an verknüpfte Fakten im Graph gebunden sind, sinkt das Risiko von Halluzinationen deutlich – vorausgesetzt, die zugrunde liegenden Daten sind korrekt und die Anwendung erzwingt Quellen- bzw. Referenzierungspflicht.

3) Governance: Automatisierung, die man kontrollieren kann

Was passiert, wenn ein automatisch erzeugter Arbeitsplan ungeprüft ins ERP wandert – und die Vorgabezeit nicht stimmt? Oder wenn ein KI-Vorschlag auf einer veralteten Werksnorm basiert, die längst abgelöst wurde? Wer KI in ERP/MES-nahen Prozessen nutzt, braucht harte Leitplanken. Sonst wird aus Automatisierung unkontrollierbare Blackbox.

Vier Anforderungen haben sich in der Praxis als entscheidend erwiesen:

1. Quellenpflicht: Jeder Vorschlag muss auf konkrete Daten oder Normen verweisen, nicht nur „klingt plausibel“. Wenn die Plattform nicht sagen kann, woher eine Empfehlung kommt, darf sie nicht in ein führendes System geschrieben werden.

   
   

2. Versionierung: Regeln, Normen und Ableitungslogiken sind eindeutig einem Stand zugeordnet. Ohne das ist nicht nachvollziehbar, ob ein Arbeitsplan auf Basis der aktuellen oder einer veralteten Vorgabe entstanden ist.

   
   

3. Freigabeworkflows: Je höher das Risiko oder je neuer eine Variante, desto mehr menschliche Prüfung vor dem Schreiben in ERP/MES. Automatik braucht klar definierte Grenzen – neue Werkstoffklassen oder neue Fertigungsverfahren werden standardmäßig eskaliert.

   
   

4. Monitoring: Wenn geplante Zeiten und tatsächliche Zeiten aus der Fertigung systematisch auseinanderlaufen, ist das ein Signal, dass Planzeiten oder Regeln gepflegt werden müssen.

V. Was Sie mitnehmen sollten: drei Gedanken für Ihren Weg

1) Der schnellste Hebel: das Vorhandene durchgängig nutzen

Viele fokussieren zuerst auf „mehr Konfiguration“. Der schnellere Hebel ist häufig: den bereits konfigurierbaren Anteil wirklich durchgängig zu nutzen – bis zum freigabefähigen Arbeitsplan, zur Montageanweisung und zum Prüfplan. Dann verschiebt sich Arbeit von Neuerstellung zu Validierung.

2) Nicht automatisierbar heißt nicht: nicht unterstützbar

Der kundenindividuelle Anteil wird oft vorschnell als „da geht nichts“ abgetan. Dabei gibt es fast immer historisches Wissen – ähnliche Teile, bewährte Arbeitspläne, frühere Entscheidungen. Wer dieses Wissen auffindbar und verknüpfbar macht, gibt dem Planer einen belastbaren Startpunkt statt eines leeren Blatts. Das ist kein Ersatz für Erfahrung, aber ein Hebel, der Stunden spart.

3) Die Rolle des Industrial Engineers wird anspruchsvoller – nicht überflüssig

KI ersetzt hier vor allem Such- und Dokumentenarbeit – also genau die Sachbearbeiterarbeit, die heute einen Großteil der Ingenieurszeit frisst. Die menschliche Arbeit verschiebt sich zu Entscheidungen, Risikoabwägung, Optimierung und Freigabe. Wer hier investiert, macht nicht den Ingenieur überflüssig, sondern seine Arbeit wirkungsvoller.

Fazit: Drei Monitore, eine Menge Sachbearbeiterarbeit, und mittendrin ein Ingenieur, der eigentlich Besseres zu tun hätte. Das muss nicht so bleiben. Die technischen Bausteine sind da – wer anfängt, sie zusammenzusetzen, wird schneller am Ziel sein als die, die auf die perfekte Datengrundlage warten.

Über den Autor

Ich bin Patrick Kübler, Maschinenbauingenieur und Mitgründer von wailand. In über 10 Jahren und mehr als 30 Industrieprojekten – vom Shopfloor bis zur Vorstandsebene, vom Mittelständler bis zum MDAX-Konzern – habe ich erlebt, wie viel Ingenieurszeit für Sachbearbeiterarbeit verloren geht.

Genau dafür haben mein Mitgründer Martin Peters und ich wailand gebaut: eine Plattform, die die Variantenentstehung im Maschinen- und Anlagenbau durchgängig automatisiert. Konkret heißt das: wailand verbindet CPQ, PLM, CAx, ERP und MES über eine Integrationsschicht, verknüpft Produkt- und Fertigungswissen in einem Knowledge Graph und automatisiert darauf aufbauend Engineering-Prozesse – von der Ähnlichkeitssuche über die Arbeitsplanerstellung bis zur Freigabe. Jeder Vorschlag ist nachvollziehbar, versioniert und an Quellen gebunden.

Wenn Sie vor ähnlichen Herausforderungen stehen oder einfach in den Austausch kommen möchten: Schreiben Sie mir auf LinkedIn oder an info@wailand.io.