Angebotskomplexitäts-Risikoerkennung

Das echte Ausmaß des Problems

Der Werkzeugbau ist strukturell ein Hochrisiko-Kalkulationsfeld. Jeder Auftrag ist ein Unikat. Die WBA Aachener Werkzeugbau Akademie hat in ihrer Benchmark-Studie “Erfolgreich Kalkulieren im Werkzeugbau” (Boos, Pitsch, Salmen, Wiese, Kelzenberg) dokumentiert, dass Kosten- und Terminkennzahlen bei einer Vielzahl von Werkzeugen von den zuvor kalkulierten Werten abweichen — und dass der Hauptgrund das Erfahrungswissen ist, das in einzelnen Mitarbeitenden steckt und nicht systematisch zugänglich gemacht wird.

Das IPH Institut für Integrierte Produktion Hannover hat in seinem AutoKalK-Projekt mit Paul Beier GmbH und ACATEC Software eine zentrale Kennzahl erhoben: Die Auftragswahrscheinlichkeit je manuellem Angebot liegt bei etwa 5 Prozent. Das bedeutet: Für jeden gewonnenen Auftrag werden typischerweise 19 Angebote erstellt, die keinen Umsatz generieren. Bei 3,3 Stunden Kalkulationsaufwand je Anfrage (Branchenmessung von innoby.de aus realen Werkzeugbaubetrieben) sind das 63 Stunden Kalkulationsarbeit pro gewonnenem Auftrag — allein für die Angebotserstellung.

Die ökonomische Konsequenz:

• Unterkalkulierte Aufträge entstehen, wenn Komplexitätstreiber übersehen werden. Der Auftrag wird gewonnen — und frisst Deckungsbeitrag, den das Unternehmen nie eingeplant hat
• Überkalkulierte Angebote entstehen aus Risikoaufschlägen, die nicht präzise genug differenzieren — das Unternehmen verliert Aufträge, die profitabel gewesen wären
• Wissensverlust bei Personalwechsel: Wenn der erfahrene Kalkulator das Unternehmen verlässt, verlässt das Kalkulationswissen das Unternehmen mit — ohne dass jemals eine Übergabe stattgefunden hat

Besonders kritisch sind versteckte Komplexitätstreiber, die in Kombinationen wirken. Einzeln erkennbar, zusammen gefährlich:

• Enge Toleranzen (unter 0,01 mm) an mehreren zusammenwirkenden Funktionsflächen gleichzeitig
• Legierungsspezifika (Warmarbeitsstahl H13, HSS-PM-Stahl, Titaneinsätze), die Sonderbearbeitungsprozesse erfordern
• Kundengestellte Komponenten (Normteile, Heizkanalkomponenten, Formaufbauten), die die Koordinationsbelastung erhöhen
• Undefinierte Oberflächenanforderungen (z. B. “Hochglanz” ohne Ra-Angabe), die Auslegungsspielraum und Nacharbeitsrisiko erzeugen
• Geometrische Sondermerkmale (Freiformflächen, Hinterschnitte, komplexe Schieber-Kinematik)

Jede dieser Kategorien erhöht das Unterkalkulationsrisiko spürbar. Ihre Kombination in einer Anfrage erhöht es exponentiell — und genau dieses Kombinationsrisiko liegt außerhalb dessen, was eine einzelne Person in 3 Stunden zuverlässig erkennen kann.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Zeitersparnis basiert auf Branchenerhebung (innoby.de) und IPH Hannover AutoKalK-Projektergebnissen (20–40 % Zeitreduktion Angebotsphase); eigene Erfahrungswerte aus Pilotprojekten.

Entscheidend ist: Das System spart nicht nur Zeit. Es bringt Konsistenz in einen Prozess, der heute stark vom individuellen Tagesstand eines einzelnen Mitarbeitenden abhängt. Ein Kalkulator, der seit drei Jahren alle Aufträge kennt, ist an guten Tagen unschlagbar — aber er ist morgen krank, nächstes Jahr in Rente, und gestern hat er die Anfrage in 20 Minuten überflogen statt in 3 Stunden.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Die Kalkulation eines Angebots geht von durchschnittlich 3–4 Stunden auf unter 1,5 Stunden zurück — nicht weil das System die Kalkulation abnimmt, sondern weil der Kalkulator sofort weiß, wo er besonders genau hinschauen muss. Nicht bei der Standardgeometrie im Kern, sondern bei den drei markierten Risikokombinationen in der Anfrage. Das ist der eigentliche Zeitgewinn: fokussierte Aufmerksamkeit statt Rasterfahndung. Nicht auf 5/5 gesetzt, weil der Kalkulator weiter unverzichtbar ist — das System warnt und priorisiert, entscheidet aber nicht.

Kosteneinsparung — mittel (3/5) Der Effekt ist real, aber indirekt und erst mit Verzögerung sichtbar. Wenn weniger Aufträge mit 20–30 % Kostenüberschreitung abgewickelt werden, verbessert sich der Deckungsbeitrag messbar — aber die Kausalität lässt sich erst nach 6–12 Monaten Produktivbetrieb belegen. Weniger sofort greifbar als ein Tool, das direkt Rechnungskosten reduziert. Deshalb nicht höher als 3 — Platz nach oben lassen für Anwendungsfälle mit direkter Kostenersparnis.

Schnelle Umsetzung — niedrig (2/5) Das ist das ehrlichste Element dieser Bewertung. Ein ML-Modell für Angebotskomplexität braucht Trainingsdaten — konkret: historische Anfragen mit dokumentierten Ist-Kosten und Soll-Kosten aus der Nachkalkulation. Wer diese Daten nicht im ERP hat, muss zuerst ein Jahr lang konsequent nachkalkulieren und erfassen, bevor das System lernen kann. Hinzu kommen 3–6 Monate Pilotaufbau. Ein Werkzeugbaubetrieb, der morgen starten will, startet heute nicht produktiv. Das unterscheidet diesen Use Case von SaaS-Tools, die in einem Tag einsatzbereit sind.

ROI-Sicherheit — mittel (3/5) Der ROI ist messbar — aber erst nach ausreichend Auftragshistorie, die zeigt, wie stark sich die Trefferquote bei Hochrisiko-Anfragen verbessert hat. Wer vorher keine Nachkalkulation systematisch gemacht hat, hat keinen Vergleichswert. Das macht den ROI-Nachweis in den ersten 12 Monaten schwierig. Realistisch messbar ab Monat 12–18 nach Produktivstart.

Skalierbarkeit — hoch (4/5) Das Modell verbessert sich mit jedem weiteren abgeschlossenen Auftrag. Mehr Anfragen, mehr Auftragstypen, neue Materialien — das System lernt mit. Kein proportionaler Mehraufwand für den Kalkulator. Ein Betrieb, der heute 200 Anfragen im Jahr bearbeitet und auf 400 wächst, braucht dafür keinen zweiten Kalkulator, wenn das System die Risikosortierung übernimmt.

Richtwerte — stark abhängig von ERP-Datenqualität, Auftragsvolumen und Bandbreite der Anfragentypen im Betrieb.

Was das System konkret macht

Die technische Grundlage ist eine Kombination aus Machine Learning und NLP. Das klingt komplex — der Kernmechanismus ist im Prinzip folgender:

Das System hat Zugriff auf alle historischen Anfragen und die dazugehörigen Nachkalkulationen aus dem ERP. Es lernt: “Welche Merkmalskombinationen in einer Anfrage korrelierten in der Vergangenheit mit Aufträgen, die über Budget liefen?” Und welche Kombinationen waren konstant profitabel?

Für eine neue Anfrage läuft dann folgendes ab:

1. Merkmalsextraktion — Aus dem PDF, dem STEP-Modell oder dem Anfragetext werden relevante Parameter extrahiert: Toleranzklassen, Materialspezifikationen, Oberflächenanforderungen, Geometrietypen, Kundenspezifika, Sonderanforderungen aus dem Textblock
2. Ähnlichkeitssuche — Das System sucht in der Projekthistorie nach strukturell ähnlichen Aufträgen: gleiche Materialklasse, ähnliche Toleranzen, ähnlicher Werkzeugtyp. Was hat dieser Auftragstyp in der Vergangenheit im Mittel gekostet?
3. Risiko-Score — Basierend auf dem Abgleich mit der Projekthistorie und erkannten Hochrisiko-Kombinationen berechnet das System einen Risikoscore: Wie wahrscheinlich ist eine signifikante Kostenüberschreitung bei diesem Auftrag, wenn zum aktuellen Kalkulations-Ergebnis keine Risikoprämie hinzukommt?
4. Begründung — Das System erklärt, welche Merkmale den Score treiben: “Enge Toleranz an Trennfuge kombiniert mit H13 im gehärteten Zustand — in 7 von 9 ähnlichen Aufträgen 15–35 % über Kalkulation.”

Was das System nicht macht: Es entscheidet nicht, ob das Angebot rausgeht und zu welchem Preis. Das bleibt beim Kalkulator. Das System ist ein Frühwarnsystem, kein Autopilot.

Komplexitäts-Signale in Anfragedokumenten

Dies ist der Kern des Anwendungsfalls, der ihn von generischen KI-Tools unterscheidet. Ein erfahrener Kalkulator trägt implizit eine Musterbibliothek im Kopf — welche Anfragen “komisch riechen”. KI macht diese Musterbibliothek explizit und skalierbar.

Die wichtigsten Signalkategorien, die in realen Werkzeugbau-Anfragen als Risikoindikatoren wirken:

Toleranzkombinationen Einzelne enge Toleranzen (unter ±0,005 mm) sind handhabbar. Gefährlich wird es bei mehreren engen Toleranzen, die miteinander in Wechselwirkung stehen — Toleranzstapelung, die bei der Kalkulation oft unterschätzt wird. Signal: Mehrere kritische Flächen mit unterschiedlichen, aber funktional abhängigen Toleranzangaben.

Materialspezifika und Wärmebehandlungsanforderungen Warmarbeitsstähle (H11, H13), PM-Stähle (ASP2023, Vanadis) und Speziallegierungen erfordern angepasste Bearbeitungsparameter, höheren Werkzeugverschleiß und oft Spezialdienstleister für Wärmebehandlung. Signal: Werkstoffangabe außerhalb der betriebsüblichen Standardpalette.

Undefinierte oder widersprüchliche Oberflächenanforderungen “Hochglanzpoliert” ohne Ra-Angabe, “keine Bearbeitungsspuren sichtbar” oder widersprüchliche Anforderungen zwischen technischer Zeichnung und Textbeschreibung erzeugen Auslegungsspielraum — und damit Nacharbeitsrisiko. Signal: Oberflächenanforderungen in Prosaform statt nach DIN/ISO.

Kundengestellte Komponenten Wenn der Kunde Heizkanalkomponenten, Normteile oder Sondereinsätze stellt, entstehen Koordinationsaufwand, Terminrisiken und Schnittstellenprobleme, die in der Kalkulation oft nicht ausreichend abgebildet werden. Signal: Teileliste mit “kundenseitig geliefert”.

Freiformflächen und komplexe Kinematik Mehr als zwei Schieberachsen, Schrägflächen mit Hinterschnitten oder Freiformflächen mit Designanforderung (Class-A-Oberflächen für Sichtbauteile) multiplizieren den Programmieraufwand und erfordern mehrachsige Bearbeitung. Signal: 3D-Modell mit hoher Flächenzahl oder expliziter Designanforderung.

Nicht-standardisierte Toleranzangaben Anfragen, in denen Toleranzen nicht nach ISO-Qualitäten (IT6, IT7 etc.) sondern als Freitextangaben erscheinen, signalisieren oft, dass der Konstrukteur die Fertigung nicht kennt. Das Risiko: Was “±0,003 mm” für den Kunden bedeutet und was es im Fertigungsprozess bedeutet, sind zwei verschiedene Dinge. Signal: Freitext-Toleranzangaben oder Toleranzen ohne Bezugssystem.

Ein gut trainiertes KI-Modell erkennt diese Signale nicht als Einzelmerkmale, sondern als Kombinationsmuster — und kann sagen: “Diese Kombination hatte in 12 ähnlichen Aufträgen im Schnitt 22 % Kostenüberschreitung. In 3 dieser Aufträge lag die Überschreitung über 40 %.”

Konkrete Werkzeuge — was wann passt

Kein einzelnes Tool löst alle Aspekte dieses Use Cases. Die richtige Wahl hängt davon ab, wo deine Daten heute liegen und welchen Teil des Problems du zuerst angehen willst.

up2parts — Selbstlernender KI-Co-Pilot speziell für Fertigungsbetriebe. up2parts analysiert 3D-Modelle (STEP, DXF), vergleicht sie mit historischen Projekten und erstellt Kalkulationsvorschläge — bis zu 80 % schneller als manuell laut Anbieter. Das System lernt aus jedem abgeschlossenen Auftrag automatisch weiter. Stärke: vollständige Integration von CAD-Analyse, Arbeitsplanerstellung und ERP-Export in einem Workflow. Preise auf Anfrage; 30-tägige Testphase verfügbar.

SIMILIA AI Cost Calculator — Speziell für Werkzeugbau und Formenbau entwickelt. SIMILIA erkennt Ähnlichkeiten zwischen neuen Anfragen und Projekten aus der eigenen Datenbank — ohne manuelle Klassifikation. Besonders geeignet für Spritzguss- und Formenbaubetriebe, die neue Anfragen systematisch gegen ihre Projekthistorie abgleichen wollen. Preise auf Anfrage.

Costimator — Für Betriebe mit intensivem Zerspanungsanteil. Costimator berechnet Zykluszeiten aus Fertigungsparametern (Drehen, Fräsen, Blechbearbeitung) — regelbasiert statt ähnlichkeitsbasiert. Weniger für Werkzeugbau mit hoher Variantenvielfalt geeignet, aber stark wenn die Kostentreiber primär in messbaren Bearbeitungszeiten liegen. Kein deutschsprachiges Interface; US-Kundenbasis; Preise auf Anfrage.

ChatGPT oder Claude als erster Schritt — Wer noch keine historischen Daten hat und das Konzept erstmals testen will: Ein gut konfigurierter LLM-Assistent kann Anfragetexte auf explizit genannte Risikosignale untersuchen und eine strukturierte Checkliste ausgeben. Kein maschinelles Lernen aus Projekthistorie, aber sofort einsatzbereit ohne technische Integration. Details dazu im letzten Abschnitt.

Wann welcher Ansatz passt:

• Bereits ERP-Daten, CAD-basierte Anfragen, Fertigungsbreite → up2parts oder SIMILIA
• Primär Zerspanungsaufträge, messbare Zykluszeiten → Costimator
• Kein strukturiertes ERP, kein Kalkulationsbudget, explorativer Einstieg → LLM-gestützter Prompt-Ansatz als Pilotstart

Datenschutz und Datenhaltung

Anfragedokumente im Werkzeugbau sind in aller Regel streng vertraulich — Zeichnungen enthalten Konstruktions-Know-how, das Kunden explizit schützen wollen. Das hat direkte Auswirkungen auf die Tool-Wahl:

Cloud-gehostete Tools mit US-Datenhaltung sind für viele Werkzeugbaubetriebe ausgeschlossen — nicht nur aus DSGVO-Gründen, sondern aufgrund von NDAs, die Kunden typischerweise verlangen. Bevor ein externes System Zeichnungen verarbeitet, muss mit dem Kunden und dem eigenen Datenschutzbeauftragten geklärt werden, ob das erlaubt ist.

EU-gehostete Tools (up2parts, SIMILIA) sind in einer besseren Ausgangslage, aber der Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO muss trotzdem geschlossen werden. Beide Anbieter stellen AVV-Vorlagen bereit.

On-Premise-Deployment ist für Betriebe mit besonders sensiblen Kundendaten die sicherste Option — aber auch die aufwändigste. Ein lokal betriebenes Modell erfordert eigene IT-Infrastruktur und ein Entwicklerteam oder -dienstleister für Setup und Pflege.

Praktische Empfehlung: Kläre vor dem Tool-Auswahlprozess, welche Datenkategorie in eure Anfragen fällt. Wenn Kunden-NDAs keine Weitergabe an Drittanbieter erlauben, ist der Pilotstart mit einem lokalen LLM-Ansatz (z. B. lokal betriebenes Open-Source-Modell) sinnvoller als eine sofortige Cloud-Integration.

Was es kostet — realistisch gerechnet

Einmalige Aufbaukosten

• Datenaufbereitung (ERP-Export, Bereinigung historischer Auftrags- und Nachkalkulationsdaten): typisch 3–8 Wochen interne Arbeit oder 5.000–15.000 Euro externe Beratung
• Software-Implementierung und Pilotphase: je nach Tool und Integrationstiefe 10.000–40.000 Euro für externe Begleitung; deutlich weniger bei reiner SaaS-Nutzung ohne individuelle Anpassung
• Bei Cloud-Tools (up2parts, SIMILIA): geringerer Einrichtungsaufwand, dafür laufende Lizenzkosten

Laufende Kosten

• up2parts und SIMILIA: Preise auf Anfrage; basierend auf Marktvergleichen für ähnliche Fertigungssoftware typischerweise im Bereich 500–2.000 Euro/Monat je nach Nutzungsvolumen
• LLM-API-Kosten bei eigenem Prompt-basierten Ansatz: 50–300 Euro/Monat je nach Anfragevolumen
• Interne Pflegezeit: 2–4 Stunden/Monat für Modell-Feedback und Datenkuration

Was dagegen gerechnet werden kann Ein Werkzeugbaubetrieb mit 150 Anfragen pro Jahr und einem durchschnittlichen Auftragswert von 30.000 Euro: Wenn 15 % der Aufträge (also 22 von ~150 eingegangenen, bei 5 % Abschlussquote rund 7–8 gewonnene Aufträge pro Quartal) Kostenüberschreitungen von 20–30 % aufweisen, sind das 7–8 × 6.000–9.000 Euro = 42.000–72.000 Euro Deckungsbeitragsverlust pro Jahr, die vermeidbar wären.

Selbst wenn das System diese Verluste nur um 50 % reduziert, ist das ein jährlicher Effekt von 21.000–36.000 Euro — genug, um die Laufzeitkosten vielfach zu rechtfertigen. Das sind Schätzungen, keine garantierten Zahlen; der tatsächliche Effekt hängt stark vom Ausgangsniveau der Kalkulationsgenauigkeit im Betrieb ab.

Wie der ROI tatsächlich gemessen wird: Nicht durch eine theoretische Rechnung, sondern durch konsequente Nachkalkulation. Wer die Anfragen, für die das System ein hohes Risiko markiert hat, systematisch nachkalkuliert — und die Anfragen, für die es niedrig markiert hat, ebenfalls — bekommt nach 6–12 Monaten eine klare Trefferkurve. Diese Kurve ist der einzige verlässliche ROI-Nachweis.

Drei typische Einstiegsfehler

1. Mit zu wenig historischen Daten starten. Der häufigste Fehler: Das Modell wird mit 30–50 Aufträgen trainiert und liefert dann unbefriedigende Ergebnisse. Die Schlussfolgerung: “KI funktioniert bei uns nicht.” Die eigentliche Ursache: Für zuverlässige Mustererkennung in einem hoch variablen Umfeld wie dem Werkzeugbau braucht ein Modell mindestens 200–500 abgeschlossene Aufträge mit Soll-Ist-Vergleich. Wer diese Basis noch nicht hat, sollte zuerst ein Jahr konsequent nachkalkulieren und die Ergebnisse strukturiert erfassen — und erst dann ein ML-basiertes System aufsetzen.

2. Risikowarnung ignorieren, weil “der Kalkulator es besser weiß”. Das System markiert einen Auftrag als Hochrisiko. Der Kalkulator kennt den Kunden seit Jahren und ist überzeugt, dass das Angebot stimmt. Das Angebot geht unverändert raus. Dieser Fehler passiert, wenn das System als Kontrollinstrument statt als Reflexionsanlass eingesetzt wird. Das Ziel ist nicht Gehorsam gegenüber dem Modell — sondern ein begründetes Gespräch: “Das System markiert diese Toleranzkombination als Risiko. Habe ich das in meiner Kalkulation berücksichtigt?” Die Antwort “Ja, ich habe das explizit eingepreist” ist legitim. Die Antwort “Ich habe es nicht bemerkt” ist der Moment, wo das System seinen Wert beweist.

3. Das Modell nicht nachpflegen, wenn sich die Fertigung ändert. Dieser Fehler ist der gefährlichste — weil er still passiert. Wenn ein Betrieb neue CNC-Maschinen anschafft, einen Prozess auf Fremdfertigung umstellt oder einen neuen Materiallieferanten hat, ändern sich die Ist-Kosten systematisch. Das Modell weiß davon nichts und lernt weiter auf Basis veralteter Verhältnisse. Nach 18–24 Monaten gibt es dann Risikowarnungen für Auftragstypen, die inzwischen gut beherrschbar sind — und keine Warnungen für neue Risikokombinationen, die das System noch nicht gesehen hat. Das Gegenmittel: Jede signifikante Änderung im Fertigungsprozess muss als “Lerngrenze” im Modell markiert werden. Ältere Daten vor dieser Grenze werden dann anders gewichtet oder ausgeblendet.

Was mit der Einführung wirklich passiert — und was nicht

Die technische Integration ist handhabbar. Was unterschätzt wird: die organisatorischen Widerstände.

Der erfahrene Kalkulator und sein Selbstverständnis. Ein Kalkulator mit 15 Jahren Werkzeugbauerfahrung hat sein Urteil auf tausende Anfragen aufgebaut. Ein System, das sagt “Ich sehe hier ein Risiko, das du vielleicht nicht siehst”, greift in dieses Selbstverständnis ein. Das ist kein Problem der Persönlichkeit — es ist eine natürliche Reaktion auf wahrgenommene Kompetenz-Infragestellung. Was hilft: Den Kalkulator von Anfang an als Experten für das Modell positionieren, nicht als Nutzer. Er entscheidet, welche historischen Aufträge als Trainingsdaten dienen, welche Risikoklassen wichtig sind, und wo das Modell liegt. Wer das System mitgebaut hat, vertraut ihm.

Die Versuchung, den Prozess umzukehren. Sobald das System läuft, entsteht manchmal der Impuls: “Warum kalkuliert der Kalkulator noch? Kann das System das nicht direkt machen?” Das ist der schnellste Weg zum Scheitern. Das System ist ein Frühwarnsystem, kein Kalkulator-Ersatz. Es erkennt Risikosignale in Anfragen — aber es kann keine Endverantwortung für einen Preis übernehmen, der am Markt bestehen muss. Der menschliche Kalkulator bleibt der Entscheidungsträger; das System gibt ihm bessere Informationsgrundlagen.

Fehlende Rückkopplungsschleife. Wer die Nachkalkulation nicht konsequent macht, verhungert das System. Das Modell lernt nur dann, wenn Ist-Kosten zurückgespielt werden. Wenn nach der Einführung die Nachkalkulation “mal wieder auf später verschoben” wird, verliert das System innerhalb von 12 Monaten seine Aussagekraft. Nachkalkulation ist kein “nice to have” für diesen Use Case — sie ist die Grundnahrung des Modells.

Was konkret hilft:

• Pilotstart mit einem Anfragentyp, für den es besonders viele historische Daten gibt (z. B. Spritzgussformen eines bestimmten Typs)
• Wöchentliches 15-minütiges Review: Welche Anfragen hat das System falsch eingeschätzt? Was war der Grund?
• Risikowarnungen immer dokumentieren — auch wenn sie sich als falsch herausstellen. Die False-Positives sind Lernmaterial.

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Der Schritt von Pilotbetrieb zu Produktivbetrieb sollte erst nach einer validierbaren Trefferquote passieren. Konkret: Das System sollte in mindestens 70 % der nachkalkulierten Hochrisiko-Aufträge eine tatsächlich überdurchschnittliche Kostenüberschreitung vorhergesagt haben, bevor es als primäres Werkzeug eingesetzt wird.

Häufige Einwände — und was dahintersteckt

“Unsere erfahrenen Kalkulatoren kennen ihre Aufträge — warum ein ML-Modell?” Das ist kein Widerspruch, sondern der Ausgangspunkt. Erfahrene Kalkulatoren sind der Grund, warum das Modell überhaupt trainierbar ist — ihre vergangenen Entscheidungen und die Nachkalkulationen, die zeigen, wo sie recht hatten und wo nicht, sind die Trainingsdaten. Aber selbst der beste Kalkulator hat kognitive Grenzen: Er kann nicht gleichzeitig 500 vergangene Aufträge im Gedächtnis halten. Er ist nicht verfügbar an dem Tag, an dem drei Anfragen gleichzeitig reinkommen und eine davon in zwei Stunden beantwortet sein muss. Und wenn er in drei Jahren in Rente geht, nimmt er sein Urteilsvermögen mit — sofern es nicht systematisch dokumentiert wurde. Das Modell institutionalisiert genau dieses Urteilsvermögen. Es augmentiert den Kalkulator, es ersetzt ihn nicht.

“Unsere Anfragen sind zu individuell für KI.” Das ist das häufigste Missverständnis über ML im Werkzeugbau. Kein Auftrag ist identisch — aber strukturelle Ähnlichkeiten sind vorhanden. Ein Werkzeug mit H13 im Warmarbeitseinsatz für Druckguss ist nicht dasselbe wie ein Spritzgusswerkzeug, aber es gibt innerhalb dieser Kategorien wiederkehrende Muster in der Kostentreiber-Logik. Das System sucht nicht nach identischen Aufträgen, sondern nach strukturellen Ähnlichkeiten in den Risikosignalen. Das funktioniert auch bei hoher Variantenvielfalt — es braucht nur genug Daten, um diese Ähnlichkeiten statistisch zu finden.

“Wir müssten erst unsere ERP-Daten aufräumen.” Richtig — und das ist kein Gegenargument, sondern der erste Schritt. Die Datenaufbereitung ist Arbeit, aber sie ist Arbeit, die sich auch unabhängig vom KI-Projekt lohnt. Ein Betrieb, der seine historischen Kalkulationen und Nachkalkulationen nicht zuverlässig abrufen kann, hat ein Controlling-Problem, nicht nur ein KI-Startproblem. Das KI-Projekt kann der Anlass sein, dieses Controlling-Problem endlich zu lösen.

Woran du merkst, dass das zu dir passt

Folgende Punkte sprechen für eine Einführung:

• Du bearbeitest mehr als 200 Anfragen pro Jahr — erst ab diesem Volumen hat das Modell genug Trainingsdaten, um zuverlässige Muster zu erkennen
• Dein ERP oder Kalkulationssystem enthält historische Soll-Ist-Vergleiche für abgeschlossene Aufträge — ohne diese gibt es keine Grundlage für maschinelles Lernen
• Du hast ein bis zwei erfahrene Kalkulatoren, deren Wissen du institutionalisieren willst — weil Personalwechsel das größte Risiko für die Kalkulations-Qualität ist
• Du verlierst regelmäßig Deckungsbeitrag durch Aufträge, bei denen das Ist deutlich über dem Soll lag, ohne zu wissen warum
• Deine Anfragen kommen digital (PDF, STEP, DXF, E-Mail) und enthalten strukturierte technische Daten — rein mündliche oder telefonische Anfragen sind für diesen Ansatz nicht geeignet

Wann es sich nicht lohnt — drei harte Ausschlusskriterien:

1. Unter 20 Mitarbeitenden oder unter 200 Anfragen pro Jahr. Das Datenvolumen reicht für zuverlässiges Modelltraining nicht aus. In diesem Fall ist ein strukturierter Komplex-Checklisten-Prozess effizienter als ein ML-Modell. Ein LLM-Prompt-Ansatz (siehe nächsten Abschnitt) kann als niedrigschwelliger Einstieg funktionieren — ohne Modellanforderungen.

2. Kein ERP mit protokollierten Ist-Stunden je Auftrag. Wer keine Nachkalkulation systematisch erfasst, hat keine Grundwahrheit für das Modell. Ohne Wissen darüber, welche historischen Aufträge profitabel waren und welche nicht, kann kein Modell lernen, was Unterkalkulationsrisiko bedeutet. Zuerst 12 Monate konsequent nachkalkulieren — dann KI.

3. Anfragen ausschließlich telefonisch oder ohne digitale Dokumentation. Wenn Anfragen mündlich eingehen und der Kalkulator die Anforderungen direkt aus dem Kundengespräch schätzt, gibt es keinen Text- oder CAD-Corpus, den das System analysieren könnte. Die Grundvoraussetzung ist eine digitale Anfragedokumentation — PDF, technische Zeichnung, E-Mail-Text oder STEP-Datei. Ohne diese Grundlage fehlt der Rohdaten-Input.

Das kannst du heute noch tun

Kein ML-Projekt, kein ERP-Export — einfach einen Standard-LLM nutzen, um erste Erfahrungen mit strukturierter Risikoanalyse zu machen. Öffne ChatGPT oder Claude, kopiere die technische Beschreibung aus deiner nächsten Anfrage (ohne schutzbedürftige Zeichnungen) und verwende folgenden Prompt:

Das ist kein Ersatz für ein trainiertes ML-Modell — aber es ist ein sofortiger erster Schritt, der zeigt, ob strukturierte Risikoanalyse in deinem Betrieb Mehrwert bringt. Wenn dieser Prompt in den nächsten 10 Anfragen zweimal einen Risikofaktor aufdeckt, den der Kalkulator sonst übersehen hätte, ist das der Beleg dafür, dass ein systematischerer Ansatz sich lohnt.

Quellen & Methodik

• WBA Aachener Werkzeugbau Akademie, “Erfolgreich Kalkulieren im Werkzeugbau” (Boos, Pitsch, Salmen, Wiese, Kelzenberg; Studie verfügbar auf werkzeugbau-akademie.de). Grundlage für die Charakterisierung der Kalkulationsherausforderungen im Werkzeugbau: Erfahrungswissensabhängigkeit, Abweichungen zwischen Vorkalkulation und Ist-Kosten, fünf Erfolgsfaktoren für effiziente Kalkulation.
• IPH Institut für Integrierte Produktion Hannover, AutoKalK-Projekt (mit Paul Beier GmbH Werkzeug- und Maschinenbau, ACATEC Software GmbH; Laufzeit 2010–2012; Pressemitteilung auf iph-hannover.de). Ergebnis: 20–40 % Zeitersparnis in der Angebotsphase; Auftragswahrscheinlichkeit je manuellem Angebot ca. 5 %; KI-gestützte Geometrieanalyse bei Folgeverbundwerkzeugen validiert.
• Innoby GmbH, “KI-Angebotskalkulation für Werkzeugbau: 3x schneller” (innoby.de/angebotskalkulation-werkzeugbau, Stand April 2026). Branchenerhebung: durchschnittlich 3,3 Stunden manuelle Kalkulationszeit je Anfrage in Werkzeugbaubetrieben.
• up2parts GmbH Produktdokumentation (up2parts.com, Stand April 2026). Anbieteraussagen: bis zu 80 % schnellere Kalkulation und Arbeitsplanerstellung; selbstlernend aus abgeschlossenen Aufträgen.
• Kostenwerte und ROI-Schätzungen: eigene Modellrechnung auf Basis öffentlich zugänglicher Branchenkennzahlen; keine repräsentative Studie. Tatsächlicher ROI abhängig von Ausgangsniveau der Kalkulationsgenauigkeit im konkreten Betrieb.
• Fraunhofer IPT Pressemitteilungen zu Einzelfertigung und Werkzeugbau (ipt.fraunhofer.de, Projekte zur stochastischen Fertigungsplanung und Angebotsmanagement in Einzelfertigung, Stand April 2026).

Du willst wissen, ob deine ERP-Daten als Grundlage für ein solches System taugen — und was der realistische erste Schritt wäre? Meld dich — das klären wir in einem kurzen Gespräch.