Supply-Chain BoM-Reasoning: Knowledge Graph + Multi-Hop

Pexon Consulting | 10 Min. Lesezeit | 13.06.2026

TL;DR

Supply Chain BoM Reasoning ist 2026 die Antwort auf das Mittelstands-Problem: Bei einer Lieferanten-Disruption (Werkbrand, Insolvenz, geopolitische Krise) braucht die Geschäftsleitung in Stunden — nicht Tagen — die Antwort, welche eigenen Produkte betroffen sind, welche Kunden, welche Umsätze. Klassische ERP-Tools zeigen die Bill of Materials linear, aber das Multi-Hop-Reasoning entlang Komponente → Lieferant → Standort → Risiko fehlt. Pexon Consulting baut den Knowledge Graph als Ergänzung zu eurem ERP — Disruption-Antwort in Sekunden statt Tagen.

Warum BoM-Reasoning so hart ist

Wir hören das aktuell wöchentlich: Eine Beschaffungsleitung bekommt die Nachricht, dass ein Lieferant gerade insolvent geht oder eine Region wegen geopolitischer Spannungen ausfällt. Die nächste Frage von der Geschäftsleitung: „Welche unserer Produkte sind betroffen, welche Kunden, welcher Umsatz“. Die Beschaffungsleitung soll antworten — und kann nicht.

Das Problem liegt nicht im fehlenden Daten — alles steht im ERP. Bills of Materials, Lieferanten-Stammdaten, Kunden-Aufträge, Umsätze. Das Problem ist die strukturelle Verbindung. Klassische ERPs zeigen das hierarchisch: Produkt enthält Komponenten, Komponenten haben Lieferanten. Die umgekehrte Richtung — „welche Produkte hängen an Komponente X“ — geht nur über aufwendige Queries oder händische Recherche.

Bei einem Pilotkunden im Maschinenbau hat genau diese Multi-Hop-Frage bei einer großen Asien-Disruption Mitte 2025 sechs Tage gedauert. Ergebnis: 23 Produkt-Familien betroffen, 47 Kunden, geschätzter Umsatz-Risiko in Höhe von 14 Mio EUR. Bei einer schnelleren Antwort hätte die Beschaffung schon ab Tag 1 Alternativen sourcen können, statt erst ab Tag 7. Die strukturelle Antwort heißt BoM Knowledge Graph.

Der Knowledge Graph für BoM-Reasoning

Wir bauen den Graph mit sechs Entitäten-Typen.

Produkt. Konkretes Endprodukt aus dem Verkaufs-Katalog.

Komponente. Bauteil aus der Stückliste, von der einfachen Schraube bis zur komplexen Baugruppe. Komponenten können selbst Komponenten enthalten (verschachtelte BoMs).

Lieferant. Bezugs-Quelle pro Komponente. Eine Komponente kann mehrere alternative Lieferanten haben.

Standort. Physischer Produktions-Standort des Lieferanten. Geographische Lage als Knoten-Attribut.

Kunde. Wer hat das Produkt bestellt, mit welchem Auftrag, welcher Liefer-Termin, welcher Umsatz-Wert.

Risiko. Risiko-Klassifikationen (Geo-Risiko, Bonitäts-Risiko, Single-Source, etc.) als verbindende Knoten.

Beziehungen:

• Produkt --contains--> Komponente (mit Mengen-Verhältnis als Edge-Attribut)
• Komponente --suppliedBy--> Lieferant
• Lieferant --locatedAt--> Standort
• Standort --hasRisk--> Risiko
• Produkt --orderedBy--> Kunde (mit Auftragsdaten als Edge-Attribute)
• Komponente --alternativeFor--> Komponente (für Drop-In-Ersatzteile)

Damit ist die Multi-Hop-Frage als Cypher-Query stellbar. „Welche Produkte enthalten Komponenten, die von Lieferanten mit Standort in Risiko-Region X kommen, und welche Kunden haben diese Produkte bestellt“ — das ist ein 5-Hop-Traversal, das in einer Graph-Datenbank in Sekunden läuft.

Disruption-Response in vier Schritten

Schritt 1: Initial-Diagnose. Bei einer Disruption-Meldung (Lieferanten-Insolvenz, Werkbrand, geopolitische Eskalation) füttert der Beschaffungs-Mitarbeiter den Copilot mit der Information. Output: Liste der betroffenen Komponenten, Produkte, Kunden mit Umsatz-Risiko-Bewertung. Zeitrahmen: unter 5 Minuten.

Schritt 2: Alternativ-Lieferanten-Suche. Pro betroffener Komponente schlägt der Copilot die alternativen Lieferanten vor, mit Bewertung der Verfügbarkeit (Stamm-Datensatz), der Liefer-Konditionen (historische Verträge) und der Qualifikations-Status (QM-Daten). Zeitrahmen: 5-15 Minuten.

Schritt 3: Kunden-Kommunikation-Vorbereitung. Für jeden betroffenen Kunden generiert der Copilot einen Vorschlag für die Kommunikation — was bedeuten die Lieferungs-Verzögerungen, welche Alternativen können angeboten werden. Zeitrahmen: 30-60 Minuten Review.

Schritt 4: Mitigation-Plan. Der Copilot strukturiert einen Mitigation-Plan: Welche Alternativ-Lieferanten qualifiziert werden müssen, welche Bestände aus Sicherheits-Lager genutzt werden können, welche Kundentermine verschoben werden müssen. Mit dem Beschaffungs-Team in 2-4 Stunden finalisierbar.

Insgesamt: Von Disruption-Meldung bis vollständigem Mitigation-Plan in 4-8 Stunden statt 6-10 Tagen.

Beyond Disruption: kontinuierliches Risiko-Management

Der BoM Knowledge Graph hat Wert über Disruption-Response hinaus. Drei kontinuierliche Use-Cases.

Risiko-Dashboard. Geschäftsleitung sieht in Echtzeit, welche Risiko-Konzentrationen bestehen — Single-Source-Komponenten, Geo-Konzentration in einer Region, Bonitäts-Verschlechterung bei wichtigen Lieferanten. Updates wöchentlich oder monatlich.

Pre-Sourcing-Bewertung. Bei einer neuen Produktentwicklung kann der Copilot bewerten, welche Komponenten-Wahl Risiko-Profile reduziert („wenn ihr Komponente A statt B nutzt, sind drei Lieferanten weniger Single-Source“).

Compliance-Tracking. Bei Lieferketten-Gesetz-Anforderungen (LkSG): Welche Lieferanten in unserer Kette haben Tier-2/3-Lieferanten in Hochrisiko-Regionen. Der Graph kann das in unter 60 Sekunden beantworten.

Pexon-Sprint für BoM Knowledge Graph

Wir liefern das als 10-14-Wochen-Sprint. Lieferumfang: SAP-/Microsoft-Dynamics-/proAlpha-Anbindung über REST/OData, Knowledge-Graph-Aufbau in Neo4j oder Memgraph, Copilot-Frontend mit Multi-Hop-Query-Verständnis, Risiko-Dashboard, Schulung der Beschaffungs-Profile.

Investment 175-260k EUR je nach Komplexität der BoMs und Lieferanten-Anzahl. Bei Stücklisten mit 50.000+ Positionen tendenziell teurer.

Häufig gestellte Fragen

Wie verhält sich das mit klassischen SCRM-Tools wie LlamaIndex oder resilinc?

SCRM-Tools wie resilinc oder Interos liefern externe Risiko-Daten zu Lieferanten. Wir nutzen diese als Input-Quelle für unseren Graph, betreiben aber das Multi-Hop-Reasoning gegen eure BoMs intern. Hybrid-Setup mit externer Risiko-Daten plus interner Graph ist die häufigste produktive Variante.

Wie aktuell ist der Graph bei BoM-Änderungen?

Inkrementelles Update bei jedem ERP-Stammdaten-Change. Bei einem typischen Mittelständler mit 50-150 BoM-Änderungen pro Tag läuft der Graph mit unter 5 Minuten Verzögerung gegenüber ERP.

Was, wenn unsere BoM-Datenqualität nicht gut ist?

Häufige Realität. Wir nutzen die Knowledge-Graph-Initial-Befüllung gleichzeitig als Data-Quality-Cleanup — der LLM identifiziert Inkonsistenzen, fehlende Lieferanten-Zuordnungen, doppelte Komponenten-Stämme. Output ist sowohl der Graph als auch eine Data-Quality-Report-Liste für die ERP-Profis.

Können wir das auch für indirekte Materialien nutzen?

Ja, das ist sogar ein typischer Sweet-Spot. Direkte Materialien sind in ERPs meist gut strukturiert, indirekte (Werkzeuge, Verbrauchsmaterial, Hilfsstoffe) oft nicht. Der Knowledge Graph bringt Struktur in diesen Bereich.

Wie sieht das mit Lieferanten-Geheimhaltung aus?

Daten bleiben in eurem System. Der Knowledge Graph läuft on-prem oder in eurer Cloud, keine externe Daten-Übertragung. Bei besonders sensitiven Lieferanten-Beziehungen können wir Hashes oder Pseudonymisierung einbauen.

Nächster Schritt

Wenn dein Mittelstand-Unternehmen unter Supply-Chain-Komplexität leidet und die nächste Disruption fürchtet: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise dem Beschaffungs-Leiter. Du beschreibst die BoM-Komplexität und ERP-Landschaft, wir skizzieren das Setup mit Festpreis.

Verwandte Themen