Einkauf

Der fehlende Schritt vor dem agentischen Einkauf: RfX-Automatisierung

Eine KI schreibt ein RFQ in Sekunden. Das war nie der schwierige Teil.

Eine KI schreibt eine Angebotsanfrage in Sekunden, und das war nie der schwierige Teil. Eine gute Ausschreibungsunterlage braucht eine Datenbasis, die zusammenbringt, was ein Unternehmen einkauft und wie das Teil konstruiert, gefertigt und kalkuliert ist. Warum die RfX-Erstellung der praktische Test dafür ist, ob die Einkaufsdaten für Agenten taugen.

Der fehlende Schritt vor dem agentischen Einkauf: RfX-Automatisierung
Published
Author Covalyze Team
Read 11 Min. Lesezeit
Topics agentische KI im EinkaufRfX-AutomatisierungRFQ-ErstellungShould-Cost-AnalyseEinkaufsdatenDirekter MaterialaufwandDesign-to-CostKI im Einkauf
Sekunden So lange braucht ein Sprachmodell für ein RFQ-Dokument
5 Quellen ERP, Zeichnung, Entwicklung, Fertigung, Einkauf
Teileebene Hier müssen technische und kaufmännische Daten zusammenkommen
Das Ergebnis Das automatisieren, bevor ein Agent eingesetzt wird

Agentische KI im Einkauf ist ein verlockendes Bild. Agenten erkennen Sourcing-Chancen, stellen eine Lieferantenauswahl zusammen, bereiten Anfragen vor, werten Angebote aus, schlagen eine Verhandlungslinie vor und werden mit jedem Durchlauf besser darin.

Zwischen den heutigen Einkaufsprozessen und diesem Bild liegt ein Schritt, über den selten gesprochen wird. Bevor Agenten im Einkauf arbeiten können, müssen seine Ergebnisse reproduzierbar sein.

RfIs, RFQs und RfPs sind ein guter Anfang. Das Dokument selbst ist daran das Uninteressanteste. Eine wirklich gute Ausschreibungsunterlage setzt eine Datenbasis voraus, die zusammenbringt, was ein Unternehmen einkauft und wie das zugrunde liegende Teil konstruiert, gefertigt und kalkuliert ist.

Die Grenze liegt nicht bei der KI. Sie liegt beim Kontext, der ihr zur Verfügung steht.

Eine KI kann ein RFQ schreiben. Das war nie der schwierige Teil.

Geben Sie einem Sprachmodell eine Bauteilbeschreibung, und in Sekunden kommt ein professionell aussehendes RFQ zurück. Die Struktur stimmt, die üblichen Klauseln sind drin, ein Antwortformular liegt bei. Für sich genommen bringt das wenig, denn das Schreiben des Dokuments war noch nie der schwierige Teil eines Sourcing-Pakets.

Die Entscheidungen, auf die es ankommt, fallen vorher.

  • Sollen diese Teile gemeinsam vergeben werden?
  • Brauchen sie dieselben Fertigungsverfahren?
  • Welche Fähigkeiten muss ein Lieferant für dieses Paket wirklich mitbringen?
  • Liegen Teile im Paket, die technisch woanders hingehören?
  • Lassen sich Varianten zusammenfassen, bevor Lieferanten angefragt werden?
  • Mit welchen Fertigungskosten sollte der Einkauf rechnen?
  • Und wenn die Angebote zurückkommen, welche Preise verdienen einen zweiten Blick?

Eine Ausschreibungsunterlage, die diese Fragen beantwortet, ist das Ergebnis einer Analyse. Eine, die sie überspringt, ist gut formatierter Text, den vor dem Versand trotzdem jemand prüfen muss.

Die RfX-Erstellung zeigt, ob die Einkaufsdaten so weit sind

Damit wird die RfX-Erstellung zu einem brauchbaren Reifetest für den technischen Einkauf. Setzen Sie sie auf die Systeme an, die Sie ohnehin haben, und verlangen Sie genau eine Sache:

„Erstellen Sie ein versandfertiges RFQ für diese Produktfamilie.“

Ging das? Jeder Baustein der Antwort liegt bereits irgendwo im Unternehmen. Das ERP kennt Teilenummern, Lieferanten, Mengen und historische Preise. Die Zeichnung trägt Werkstoff, Maße und Toleranzen. Die Entwicklung weiß, warum eine bestimmte Vorgabe überhaupt dort steht. Die Fertigung weiß, welche Verfahren und Maschinen das Teil braucht. Der Einkauf hat die kaufmännische Historie.

Die Bausteine liegen nur in verschiedenen Systemen und meist in verschiedenen Abteilungen. Ein gutes RFQ braucht sie alle gleichzeitig.

Fünf Quellenkarten mit den Beschriftungen ERP, Zeichnung, Entwicklung, Fertigung und Einkauf, deren Linien unten in einem einzigen Feld für ein versandfertiges RFQ zusammenlaufen
Ein RFQ, auf das ein Lieferant sauber anbieten kann, braucht Antworten aus fünf Quellen gleichzeitig. An jede einzelne kommen die meisten Unternehmen heran, nur nicht im selben Arbeitsschritt.

Wenn ein Sourcing-Paket weiterhin mehrere Exporte, zwei Tabellen, zwei Gespräche mit der Entwicklung und eine Runde manueller Auslegung braucht, läuft ein autonomer Sourcing-Agent gegen dieselbe Wand. Der Unterschied ist, dass er schneller arbeitet und nicht anmerkt, welcher Kontext ihm gefehlt hat.

Fangen Sie beim Ergebnis an, nicht beim Agenten

Der nächste Schritt hin zu agentischer KI im Einkauf ist deshalb vermutlich nüchterner als der Einsatz autonomer Sourcing-Agenten. Fragen Sie zuerst, ob sich aus den Daten, die Sie haben, bereits belastbare Einkaufsergebnisse erzeugen lassen.

Ein RfX-Dokument ist ein Beispiel. Dasselbe gilt für einen Lieferantenvergleich, eine Verhandlungsvorbereitung, eine Should-Cost-Berechnung, eine Sourcing-Empfehlung oder eine Design-to-Cost-Liste. Jedes dieser Ergebnisse prüft dieselbe Frage: ob die zugrunde liegenden Informationen strukturiert, verknüpft und nachvollziehbar genug sind, um eine Entscheidung zu tragen.

Reifetest

Beide Antworten helfen weiter. Nur bei einer hat ein Agent etwas, womit er arbeiten kann.

Ein Test für Ihre Teiledaten, mit einer Frage

Wenn das System diese Ergebnisse heute zuverlässig liefert, wird der Weg zu agentischen Abläufen deutlich kürzer, weil der Agent nicht mehr bei verstreuten Quelldaten anfängt.

Infografik mit der Frage, ob vorhandene Daten eine Ausschreibungsunterlage erzeugen können, die ein Einkäufer verwenden würde, mit einer Nein-Spalte aus Exporten und Gesprächen mit der Entwicklung und einer Ja-Spalte aus Ergebnissen, die aus einem einzigen Modell entstehen

Er startet bei einem brauchbaren technisch-kaufmännischen Abbild des Produkts statt bei Exporten, die erst noch jemand deuten muss.

Deshalb lohnt der Test, bevor überhaupt ein Agent beschafft wird. Er zeigt, ob die Lücke in der KI-Schicht liegt oder eine Ebene darunter, und die Antwort sagt, wo die Arbeit tatsächlich anfällt.

Die fehlende Verbindung zwischen Entwicklung und Einkauf

Am stärksten wiegt das im Einkauf direkter Materialien, wo die Kosten im Teil selbst stecken. Ein Zukaufteil ist mehr als eine Zeile im ERP-System. Es hat einen Werkstoff und eine Geometrie. Es verlangt Fertigungsschritte, und diese Schritte verlangen Maschinen, Rüstzeit, Arbeitszeit, Energie und Kapazität. Seine Konstruktion entscheidet, welche Lieferanten es überhaupt fertigen können, seine Stückzahl bestimmt die Wirtschaftlichkeit der Fertigung, sein Produktionsstandort die Kostenstruktur. All das landet im Lieferantenpreis.

Technische Zeichnung auf einer Werkbank, darauf das passende gefräste Aluminiumbauteil, daneben ein digitaler Messschieber an einer Bohrung
Alles, was ein Lieferant einpreist, ist am Teil und auf der Zeichnung zu sehen. Im Einkaufsdatensatz steht davon fast nichts.

Die meisten Unternehmen haben dieses Wissen entlang der Funktionen aufgeteilt. Die Entwicklung hält die Spezifikation, die Fertigung das Prozesswissen, der Einkauf die Lieferanten und Preise. Die IT-Systeme sind denselben Grenzen weitgehend gefolgt und verstärken die Trennung, statt sie zu schließen.

Für agentische KI im Einkauf werden diese Grenzen zur harten Schranke. Ein Agent, der Preise kennt, aber das Bauteil nicht versteht, kann keinen technischen Einkauf betreiben. Ein Agent, der die Zeichnung liest, aber Stückzahlen und kaufmännische Konditionen nicht kennt, kann eine Beschaffungsentscheidung nicht bewerten. Eine weitere Einkaufsoberfläche obendrauf schließt diese Lücke nicht. Was sie schließt, ist eine gemeinsame Datenbasis unter den Systemen, die es bereits gibt.

Wo der Kontext abreißt

Die Übergabe läuft weiterhin über ein Gespräch

In der Praxis stellen Menschen die Verbindung zwischen Spezifikation und Preis her. Ein Einkäufer fragt, warum eine Toleranz so eng ist, ein Entwickler erklärt die Baugruppe, in die das Teil gehört, und aus zehn Minuten Gespräch folgt eine Sourcing-Entscheidung.

Entwickler und Einkäufer stehen sich an einem Arbeitstisch gegenüber, zwischen ihnen eine technische Zeichnung und ein spanend gefertigtes Stahlteil
Das Wissen ist da. Es wandert zwischen den Funktionen in Gesprächen, nicht in Daten.

Das funktioniert, und es skaliert nicht. Die Begründung bleibt bei den beiden, die das Gespräch geführt haben, und beim nächsten Teil beginnt derselbe Austausch von vorn.

An diesem Gespräch kann ein Agent nicht teilnehmen. Er arbeitet nur mit dem, was in einer für ihn lesbaren Form festgehalten ist. Deshalb zählt das Datenmodell mehr als die Oberfläche.

Was sich ändert, wenn der Kontext da ist

Der Unterschied zeigt sich, sobald technische, fertigungsseitige und kaufmännische Informationen auf Teileebene verknüpft sind. Statt einer KI eine Tabelle mit Teilenummern und Einkaufspreisen zu geben, können Sie ihr Folgendes geben:

  • Werkstoff und Geometrie
  • die zugehörigen Fertigungsverfahren
  • die nötigen Maschinenfähigkeiten
  • den geschätzten Fertigungsaufwand
  • Jahres- und Bestellmengen
  • den Produktionsstandort
  • den aktuellen Lieferanten
  • den aktuellen Preis

Die Anweisung bleibt dieselbe. „Bereiten Sie ein RFQ vor“ führt jetzt zu einem völlig anderen Ergebnis.

Qualität der Eingangsdaten

Mit einer Tabelle kann das Modell nur schreiben. Mit einem Teilemodell kann es entscheiden, was ins Paket gehört.

Dieselbe Anweisung, ein anderes Ergebnis

Das System erkennt, welche Bauteile sachlich zusammengehören und welche eine ganz andere Lieferantenfähigkeit verlangen.

Vergleich einer zweispaltigen Tabelle aus Teilenummern und Preisen mit einem Teilemodell, das Werkstoff, Geometrie, Verfahren, Maschinenfähigkeit, Aufwand, Menge, Standort, Lieferant und Preis aufführt

Es markiert das Ausreißerteil in einem Paket, in das es nicht passt, benennt die technischen Angaben, die ein Lieferant für ein korrektes Angebot braucht, und fasst Varianten zusammen, bevor jemand angefragt wird.

Es hängt außerdem den Kostenkontext an, den die Angebotsauswertung Wochen später braucht. Aus dem Dokument wird das Ergebnis einer Analyse statt das Ergebnis einer Textgenerierung, und erst dieser Unterschied macht die Automatisierung sinnvoll.

RfX-Automatisierung ist die Brücke, nicht das Ziel

Steht die Basis, fängt beim RFQ der nützliche Teil erst an. Derselbe Kontext trägt direkt weiter in die Angebote, sobald sie eintreffen.

Das System vergleicht Angebote mit bestehenden Preisen und den modellierten Fertigungskosten, zeigt, wo Lieferanten deutlich voneinander und von der Kalkulation abweichen, hebt hervor, welche Kostentreiber eine Klärung verdienen, bereitet die Verhandlungsfragen vor und sagt, ob ein Teil neu vergeben, konstruktiv geändert, mit anderen zusammengefasst oder an einen anderen Fertigungsstandort verlagert werden sollte.

An dieser Stelle wird aus der Automatisierung von Ergebnissen agentische KI im Einkauf, und der Ablauf verändert sich mit.

Zwei Prozessreihen im Vergleich: Mensch sammelt Daten, Mensch analysiert, Mensch erstellt das Dokument, gegenüber strukturierte Daten, KI-Analyse, entscheidungsreifes Ergebnis, nächster Schritt
Die Arbeit verschwindet nicht. Sie verschiebt sich vom Sammeln und Formatieren zum Entscheiden, und dort liegt der Beitrag des Einkaufs ohnehin.

Mit der Zeit lassen sich mehr dieser Schritte miteinander verknüpfen. Wie weit das sinnvoll ist, hängt an der Qualität des Kontexts darunter, also genau an der Grenze, mit der diese Überlegung begonnen hat.

Was bleibt, wenn das Sourcing-Projekt vorbei ist

Ein Sourcing-Projekt erzeugt ein RFQ, einen Stapel Lieferantenangebote, eine Verhandlungspräsentation und am Ende eine gebuchte Einsparung. Monate später ist eine Frage überraschend schwer zu beantworten.

Warum haben wir damals so entschieden?

Warum haben wir diesen Zielpreis angesetzt? Warum wurden diese Teile zusammengefasst? Warum wurde dieser Lieferant infrage gestellt? Warum sah eine bestimmte Fertigungsalternative damals attraktiv aus?

Projektergebnis

Was ein Sourcing-Projekt hinterlässt

  • Ein RFQ-Dokument und einen Ordner voller Angebote
  • Eine Verhandlungspräsentation für einen einzigen Termin
  • Eine im Controlling-Bericht gebuchte Einsparung
  • Annahmen, die im Modell eines Beraters lagen

Bleibende Datenbasis

Was eine Datenbasis hinterlässt

  • Eine Kostenlogik, in die neue Preise einfließen können
  • Bündelungsentscheidungen samt ihrer Begründung
  • Zielpreise, die sich neu rechnen lassen, wenn sich Eingangsgrößen verschieben
  • Eine Basis, gegen die sich das nächste Teil rechnen lässt

Dieselbe Sourcing-Arbeit, auf zwei Arten abgelegt. Nur die zweite hilft noch, wenn die nächste Anfrage kommt.

Liegt die Analyse auf einer bleibenden Datenbasis, bleibt die Begründung verfügbar. Neue Preise kommen hinzu, neue Lieferanten lassen sich vergleichen, neue Teile mit derselben Logik rechnen, und die Kostenannahmen ziehen mit, wenn sich Energie, Löhne und Materialindizes bewegen. Das Ergebnis läuft nicht mit dem Projekt ab, und das nächste Team fängt nicht bei null an.

Ein Agent, der eine Sourcing-Entscheidung wieder aufmachen soll, braucht dieselbe Historie. Ohne sie wiederholt er entweder die ganze Analyse von vorn oder liefert eine Empfehlung, die sehr sicher klingt und auf Annahmen beruht, die niemand einsehen kann.

Zwei Einkaufsanalysten am Schreibtisch prüfen ausgedruckte Lieferantenangebote gegen eine Vergleichsansicht auf dem Bildschirm
Bei der Angebotsauswertung wird der fehlende Kontext teuer, denn da liegen die Preise schon auf dem Tisch.

Wie COVALYZE aus Teiledaten Kontext für Agenten macht

COVALYZE baut diese Basis auf, indem es technische Produktinformationen mit Fertigungs- und Einkaufsdaten verbindet.

Es liest technische Merkmale aus Zeichnungen und anderen Entwicklungsquellen aus, leitet daraus Fertigungsverfahren und Kostentreiber ab und rechnet sie durch. Lieferantenpreise, Mengen und Sourcing-Angaben kommen als kaufmännische Ebene dazu. Heraus kommt ein strukturiertes technisch-kaufmännisches Abbild der Teile, die ein Unternehmen fertigt und einkauft.

Aus dieser Basis entstehen heute schon entscheidungsreife Ergebnisse: Should-Cost-Berechnungen, Zielpreise, Lieferantenanalysen und die RfX-Vorbereitung. Auf längere Sicht zählt, dass sich derselbe strukturierte Kontext an KI-Agenten übergeben lässt, die an Lieferantensuche, Sourcing, Angebotsauswertung, Verhandlungsvorbereitung und Design-to-Cost arbeiten.

Die RfX-Automatisierung ist damit ein früher Schritt und nicht das Endprodukt. Sie ist einer der ersten sichtbaren Belege dafür, dass die Einkaufsdaten darunter für KI überhaupt brauchbar geworden sind.

Drei Kollegen an einem Tisch in einem verglasten Besprechungsraum innerhalb eines Fertigungswerks, vor sich ein ausgedrucktes Sourcing-Paket und Musterbauteile
Die Sourcing-Entscheidung bleibt bei den Menschen im Raum. Was sich ändert, ist, wie viel Vorarbeit schon erledigt ist, wenn sie sich hinsetzen.

Eine Frage, bevor Sie auf Agenten setzen

Unternehmen, die über agentische KI im Einkauf nachdenken, können mit einem einfachen Test anfangen.

Können unsere vorhandenen Daten automatisch eine Ausschreibungsunterlage erzeugen, die ein erfahrener Einkäufer tatsächlich verwenden würde?

Lautet die Antwort Nein, löst ein zusätzlicher Agent das eigentliche Problem nicht. Er erbt die Lücke und arbeitet in ihr nur schneller.

Lautet sie Ja, wird dieselbe Datenbasis, aus der das RfX entstanden ist, zur Kontextschicht für die nächste Einkaufsentscheidung und irgendwann für einen Agenten, der Teile des Prozesses selbst ausführt.

Der Weg zu agentischer KI im Einkauf beginnt nicht beim Agenten. Er beginnt damit, das Einkaufswissen so zu strukturieren und zu verknüpfen, dass daraus Ergebnisse entstehen, die jemand bereit ist, an einen Lieferanten zu schicken.

Sehen Sie, wie COVALYZE Analytics und PartIQ aus Zeichnungen, Teiledaten und Lieferantenpreisen den technisch-kaufmännischen Kontext machen, auf dem RfX-Automatisierung und agentische KI im Einkauf beide aufsetzen.

COVALYZE Analytics

Bauen Sie die Kontextschicht, bevor Sie den Agenten bauen

Ein technisch-kaufmännisches Modell auf Teileebene, das Ausschreibungsunterlagen, Zielpreise und Verhandlungsvorbereitungen aus derselben Basis liefert.

Von der Zeichnung zum Sourcing-Paket, in Zahlen

Teile je Warengruppen-Umfang 200
bis zu verhandlungsfertigen Zielpreisen 2 Wochen
Genauigkeit beim Auslesen von Zeichnungen >95 %
Fertigungsregionen 6+
Phase 01 · das Modell, Ebene für Ebene 04 layers

Ebene wählen

Technische, fertigungsseitige und kaufmännische Daten in einem Teilemodell DSGVO-konform · Datenhaltung in der EU
Zeichnungserkennung: die technische Ebene des Teilemodells

Zeichnungserkennung: die technische Ebene des Teilemodells

>95 %

Genauigkeit beim Auslesen

10

modellierte Kostenparameter

Eine Warengruppe, bis zu 200 Teile, verhandlungsfertige Zielpreise in zwei Wochen.

Fast Track buchen