KI Prozessverbesserung: Projektdokumente in der Fertigung neu denken

Pexon Consulting | 10 Min. Lesezeit | 13.05.2026

TL;DR

KI Prozessverbesserung in Fertigungsprojekten heißt: Lastenhefte, Stücklisten, CAD-Metadaten, Bautagebücher und Abnahmeprotokolle werden nicht mehr von Hand gegeneinander geprüft, sondern von einem RAG-System indiziert und semantisch verglichen. Pexon Consulting baut diese Lösungen individuell auf Ihrer Infrastruktur — auf Azure oder On-Premises, mit Anbindung an DocuWare, M-Files, ELO oder Ihr SAP-DMS. Unsere Kunden reduzieren den Prüfaufwand pro Projektdokument von 25 Minuten auf unter 2.

Wo das Geld in Projektdokumenten verbrannt wird

Ein mittelständischer Sondermaschinenbauer mit 600 Mitarbeitern fährt im Schnitt 80 bis 120 Kundenprojekte pro Jahr. Jedes Projekt produziert zwischen 200 und 800 Dokumente — Lastenheft, Pflichtenheft, Projektstrukturplan, RACI-Matrix, Stücklisten in mehreren Versionen, CAD-Zeichnungen, Arbeitspläne, Prüfbescheinigungen, Änderungsprotokolle, Statusberichte, Bautagebücher, Abnahmeprotokolle. In Summe sammeln sich 30.000 bis 90.000 Dokumente pro Jahr.

Davon werden 60 bis 75 Prozent in einem DMS wie DocuWare, M-Files oder ELO abgelegt. Der Rest liegt in Outlook-Postfächern, auf File-Shares, in Projektordnern auf Laptops. Selbst bei sauber geführten DMS-Strukturen ist die Hauptarbeit nicht das Ablegen — sie ist das Wiederfinden und Prüfen.

Drei Schmerzpunkte sehen wir bei jedem Fertigungskunden:

Schmerzpunkt 1 — Lastenheft gegen Pflichtenheft prüfen. Der Vertrieb verhandelt mit dem Kunden ein Lastenheft mit 240 Anforderungen. Die Konstruktion schreibt darauf ein Pflichtenheft. Frage: Welche der 240 Anforderungen sind im Pflichtenheft adressiert, welche fehlen, welche sind verändert? Manuelle Prüfung kostet einen Projektingenieur 6 bis 12 Stunden — und in 80 Prozent der Fälle wird die Prüfung gar nicht systematisch gemacht, weil die Zeit fehlt. Die Lücken fallen erst beim Abnahmetermin auf.

Schmerzpunkt 2 — Änderungsprotokolle versus Realität. In einem 18-Monats-Maschinenbauprojekt entstehen 40 bis 120 dokumentierte Änderungen. Bei der Endabnahme prüft der Kunde gegen das ursprüngliche Pflichtenheft plus genehmigte Änderungen. Wenn eine Änderung umgesetzt, aber nicht protokolliert wurde, wird sie zur Mängelposition. Drei bis fünf solcher Vorfälle pro Projekt sind die Regel — und jeder kostet im Schnitt 8.000 bis 25.000 EUR Nacharbeit oder Preisnachlass.

Schmerzpunkt 3 — BOM-Konsistenz zwischen CAD, ERP und Einkauf. Die Stückliste in der CAD-Software (Solid Edge, SolidWorks, NX) wird vom Konstrukteur gepflegt. Die ERP-Stückliste (SAP, ProAlpha) vom Disponenten. Der Einkauf arbeitet mit Bestelllisten. Drei Quellen, die theoretisch synchron sein sollten und es in der Praxis nie sind. Bitkom hat 2024 für den deutschen Maschinenbau Differenzen von durchschnittlich 12 bis 18 Prozent zwischen CAD- und ERP-BOM gemessen.

Wer diese drei Punkte unter Kontrolle bringt, hebt 4 bis 7 Prozent EBIT.

Welche Dokumentenklassen sich für KI-Automatisierung eignen — und welche nicht

Nicht jedes Dokument profitiert gleichermaßen von KI. Wir teilen Projektdokumente in vier Klassen ein:

Klasse A — Strukturierte Vergleichsdokumente. Lastenhefte, Pflichtenhefte, Stücklisten, RACI-Matrizen, Prüfberichte. Diese Dokumente haben eine wiederkehrende Struktur und Vergleichslogik. Hier liefert KI-Assistenz die größten Hebel — 60 bis 85 Prozent Aufwandsreduktion sind realistisch.

Klasse B — Semi-strukturierte Protokolldokumente. Bautagebücher, Fertigungsberichte, Statusberichte, Meeting-Protokolle. Hier hilft KI bei der Extraktion (was wurde wann gemeldet, welche Mängel, welche Zusagen) und beim Cross-Referencing mit anderen Dokumenten. Aufwandsreduktion: 40 bis 60 Prozent.

Klasse C — Unstrukturierte Konstruktionsdokumente. CAD-Zeichnungen, technische Skizzen, BIM-Modelle. KI extrahiert hier Metadaten und Bemaßungen, ersetzt aber nicht die fachliche Beurteilung. Sinnvoll als Anreicherung, nicht als Hauptanwendung.

Klasse D — Vertragliche Kerndokumente. Projektvertrag, AGB, Compliance-Erklärungen. Diese Dokumente bleiben juristisch geprüft. KI kann Klauseln extrahieren und Konsistenz prüfen, aber die Entscheidung bleibt beim Juristen.

In den meisten Fertigungsprojekten lohnt der Pilot in Klasse A. Klasse B kommt in der zweiten Welle, Klasse C als langfristige Ergänzung. Klasse D heben wir gar nicht erst auf.

Wie eine KI-gestützte Dokumentenprüfung konkret arbeitet

Die Pipeline besteht aus vier Bausteinen, die wir je nach Kunde unterschiedlich kombinieren.

Baustein 1 — Document Ingestion. Eingehende Dokumente (PDF, Word, Excel, CAD-Exporte) werden über eine API-Schnittstelle oder einen DMS-Konnektor (DocuWare REST API, M-Files Web Service, ELO ECM) abgegriffen. Bei gescannten Altdokumenten läuft Azure AI Document Intelligence oder ein Vision-Language-Modell drüber. Tabellen, Stücklisten und Bemaßungen werden in strukturiertes JSON überführt.

# Beispiel: Lastenheft-Ingestion via Azure CLI
az ml batch-endpoint invoke 
  --name lastenheft-extract 
  --input "https://kundenstorage.blob/lastenheft-projekt-2024-187.pdf" 
  --output-format json
# Liefert: 240 strukturierte Anforderungen mit ID, Priorität, Akzeptanzkriterien

Baustein 2 — Vektor-Index plus Klassifikation. Anforderungen, Stücklistenpositionen und Protokolleinträge werden semantisch indiziert. Die Suche findet „Drehzahlüberwachung Hauptantrieb“ auch, wenn der Konstrukteur „RPM-Monitoring der Primärwelle“ geschrieben hat. Parallel klassifizieren wir Dokumente nach Typ und Projektphase, damit die Vergleichslogik weiß, welche Anforderung zu welchem Akzeptanzkriterium gehört.

Baustein 3 — Vergleichs-Engine. Hier kommt das Sprachmodell ins Spiel — Azure OpenAI GPT-4o, Claude Sonnet oder ein selbst betriebenes Llama 3.3 in einer EU-Region. Das Modell vergleicht zwei Dokumente (Lastenheft versus Pflichtenheft, CAD-BOM versus ERP-BOM, Pflichtenheft versus Abnahmeprotokoll) und liefert eine Lückenliste mit Belegen. Jeder Befund hat eine konkrete Quellreferenz — Seite, Absatz, Zeile.

Baustein 4 — Workflow-Integration. Die Befunde landen nicht in einer separaten KI-Oberfläche, sondern fließen zurück in den bestehenden Workflow. DocuWare-Aufgaben, M-Files-Workflows oder SAP-Workflow-Items werden automatisch angelegt. Der Projektleiter sieht die KI-Befunde in dem Tool, das er ohnehin täglich nutzt.

Wichtig: Das Modell entscheidet nichts. Es schlägt Lücken und Inkonsistenzen vor, der Mensch entscheidet. Aber statt zwei Tagen Lastenheft-Lesen hat der Projektleiter eine Stunde Sichtung einer fokussierten Lückenliste.

Drei konkrete Use Cases aus der Praxis

Bei unseren Fertigungskunden landen wir nach dem Pilot meistens auf einem von drei Use-Case-Schwerpunkten. Hier konkret, was wir gesehen haben:

Use Case 1 — Lastenheft-Pflichtenheft-Abgleich. Ein Hersteller von Verpackungsmaschinen mit 400 Mitarbeitern hatte das Problem, dass 15 bis 20 Prozent der Kundenanforderungen im Pflichtenheft nicht oder unvollständig adressiert wurden. Die Lücken fielen erst bei der Abnahme auf. Nach Einführung der KI-Prüfung sank die Quote auf unter 3 Prozent. Konkrete Einsparung: 6 von 80 Projekten pro Jahr hatten vorher Nachverhandlungen mit durchschnittlich 18.000 EUR Preisnachlass — das macht 108.000 EUR weniger Nachlass pro Jahr.

Use Case 2 — Mobile Mängelerfassung mit KI-Kategorisierung. Ein Anlagenbauer für die Lebensmittelindustrie ließ seine Servicetechniker Mängel vor Ort per Foto und Sprachnotiz erfassen. Die KI klassifiziert den Mangel, ordnet ihn der richtigen Baugruppe zu, prüft gegen das Wartungsprotokoll und legt automatisch einen Auftrag im ERP an. Die Nachpflegezeit pro Einsatz sank von 45 Minuten auf 5 Minuten. Bei 12 Technikern und 20 Einsätzen pro Tag sind das 1.600 eingesparte Stunden pro Monat.

Use Case 3 — Änderungsprotokoll-Vollständigkeit. Ein Sondermaschinenbauer hatte chronische Probleme mit unprotokollierten Änderungen. Wir haben einen Workflow gebaut, der CAD-Änderungen (über die PLM-API), ERP-Anpassungen (SAP Change Documents) und E-Mail-Korrespondenz nach Stichworten („Anpassung“, „Modifikation“, „Sonderwunsch“) indiziert und gegen die formalen Change Requests im DocuWare-System spiegelt. Lücken werden täglich gemeldet. Resultat: Von 4,2 unprotokollierten Änderungen pro Projekt auf 0,3.

Alle drei Use Cases haben gemeinsam: Der Prozess wird nicht ersetzt, sondern verlustfrei gemacht. Das Team arbeitet weiter wie bisher — nur landet nichts mehr im toten Winkel.

Architektur: Was wir konkret bauen

Die Standard-Architektur sieht für einen Fertigungskunden so aus:

Bei Kunden mit harten Compliance-Anforderungen — Wehrtechnik, Pharma, Kritische Infrastruktur — bauen wir die Lösung komplett On-Premises auf einer GPU-Box mit NVIDIA H100 oder L40S. Das macht den Pilot teurer (130.000 bis 200.000 EUR statt 75.000 bis 120.000 EUR), aber die Daten verlassen das Werk nie.

Kosten, Zeitrahmen und realistischer ROI

Ein typischer 8-Wochen-Pilot kostet zwischen 75.000 und 120.000 EUR. Enthalten sind: Anbindung an zwei DMS- oder ERP-Quellen, Setup der Ingestion- und Vergleichs-Pipeline, ein konkreter Use Case produktiv (meist Lastenheft-Abgleich oder BOM-Konsistenz), Schulung von drei Anwendern, Audit-Log und Übergabedokumentation.

Die laufenden Kosten danach hängen vom Setup ab:

• Azure-Hosting: 1.800 bis 4.500 EUR pro Monat, abhängig vom Dokumentenvolumen
• On-Premises auf eigener GPU: 700 bis 1.500 EUR pro Monat (Betrieb, Updates, Modell-Refresh), einmalig 35.000 bis 70.000 EUR Hardware
• Pflege und Weiterentwicklung: typisch 8 bis 15 Beratungstage pro Quartal, also 15.000 bis 35.000 EUR

Der ROI ist bei den meisten Fertigungskunden im ersten Jahr erreicht. Konservative Rechnung für einen Mittelständler mit 80 Projekten pro Jahr:

• Eingesparte Engineering-Zeit (Lastenheft-Abgleich): 5 Stunden pro Projekt × 80 Projekte × 110 EUR = 44.000 EUR
• Vermiedene Nachlass-Verhandlungen: 5 Projekte × 15.000 EUR durchschnittlich = 75.000 EUR
• Reduzierte BOM-Differenzen-Klärung: 2.500 Stunden pro Jahr × 95 EUR = 237.500 EUR

Konservativ 350.000 EUR Einsparung im ersten Jahr bei 120.000 EUR Pilot plus 35.000 EUR Betrieb. Amortisation in 5 bis 7 Monaten.

Worauf Sie bei der Auswahl achten sollten

Sechs Punkte, an denen wir Anbieter im Markt regelmäßig scheitern sehen:

1. DMS-Anbindung bidirektional. Lesen reicht nicht. Die Lösung muss Befunde als Aufgaben oder Workflow-Items zurückschreiben können. Sonst entsteht eine Parallel-Welt, die niemand nutzt.
2. Eigenes Modell-Fine-Tuning auf Kundendaten. Generische LLMs verstehen „Verzapfung“, „Schwalbenschwanzführung“ oder „Pneumatik-Pilotventil“ nicht aus dem Stand. Der Anbieter muss in der Lage sein, das Modell auf hauseigenes Vokabular nachzutrainen.
3. Self-Hosted-Option. Mindestens auf Anfrage. Wer nur SaaS anbietet, ist im Mittelstand-Maschinenbau nur eingeschränkt einsetzbar.
4. Audit-Log granular. ISO 9001, IATF 16949 und in Pharma-Umfeldern GMP fordern Nachvollziehbarkeit. Pauschale Logs reichen nicht — jede KI-Entscheidung muss revisionssicher protokolliert sein.
5. Quellenangabe in jedem Befund. Wenn die KI sagt „Anforderung 47 ist im Pflichtenheft nicht adressiert“, muss sie auf konkrete Seitenzahlen und Absätze verweisen. Halluzinierte Befunde ohne Quelle disqualifizieren das System.
6. Pilot in 6 bis 10 Wochen. Längere Vorlaufzeiten sind ein Warnsignal. Das Thema ist mit zwei konkreten Use Cases in einem Pilot demonstrierbar.

Häufig gestellte Fragen

Funktioniert das mit DocuWare, M-Files und ELO gleichermaßen?

Ja, alle drei haben offene REST-APIs, die wir produktiv anbinden. DocuWare hat den Vorteil des breitesten Workflow-Modells, M-Files ist semantisch am stärksten (Metadaten-orientiert), ELO bietet die tiefste SAP-Integration. Welches System die beste Basis ist, hängt von Ihrem bestehenden Setup ab — wir haben Implementierungen mit allen drei.

Was kostet eine KI-gestützte Prozessverbesserung im Vergleich zu einer klassischen DMS-Einführung?

Eine klassische DMS-Einführung (DocuWare, ELO Roll-Out) liegt bei 150.000 bis 400.000 EUR über 12 Monate. Unsere KI-Schicht obendrauf kostet 75.000 bis 120.000 EUR über 8 Wochen — also typischerweise ein Drittel bis ein Viertel der DMS-Einführung. Der Punkt ist: Sie ersetzen das DMS nicht, Sie verstärken es. Ohne DMS funktioniert auch die KI nicht.

Wie verhindern wir, dass die KI in einer Anforderungslücke falsch liegt?

Drei Mechanismen. Erstens: Jeder Befund hat eine Quellreferenz, die der Projektleiter in 30 Sekunden verifizieren kann. Zweitens: Wir kalibrieren das Modell so, dass es im Zweifel eine Lücke meldet (False Positives sind günstiger als False Negatives). Drittens: Das System lernt aus Feedback — wenn ein Projektleiter einen Befund als „kein Problem“ markiert, fließt das ins Retraining.

Müssen wir unsere bestehenden Prozesse anpassen?

In den ersten 8 Wochen nein. Wir docken an Ihre bestehenden Prozesse an. In der zweiten Welle empfehlen wir typisch zwei bis drei Prozess-Anpassungen, weil sich neue Möglichkeiten ergeben — zum Beispiel ein automatisches Review-Gate vor jeder Lastenheft-Freigabe oder ein wöchentlicher BOM-Reconciliation-Report. Diese Anpassungen sind aber Empfehlungen, keine Voraussetzung.

Was passiert mit unseren Projektdaten? Verlassen die das Haus?

Bei On-Premises-Setup nie. Bei Azure-Setup laufen die Daten über Microsofts EU-Hosting in den Regionen Frankfurt oder Westeurope. Wir konfigurieren explizit „no training“ für Azure OpenAI und signieren auf Wunsch einen AVV, der die Datennutzung auf den vereinbarten Zweck beschränkt. Bei kritischen Kunden bauen wir eine vollständig abgeschottete Umgebung ohne Internet-Anbindung.

Nächster Schritt

Wenn Sie 40 oder mehr Kundenprojekte pro Jahr fahren und mindestens einer der drei beschriebenen Schmerzpunkte (Lastenheft-Lücken, BOM-Differenzen, unprotokollierte Änderungen) Ihren Projektleitern regelmäßig Bauchweh macht, ist das Thema einen ehrlichen Pilot wert. Wir setzen mit Ihnen in 90 Minuten auf, welcher Use Case sich für den Erstaufbau am besten eignet, und welche Datenquellen wir indizieren müssen.

Verwandte Themen