Pexon Consulting | 10 Min. Lesezeit | 08.07.2026
TL;DR
Ein BOM-Reasoning-Agent liest eine Stückliste, prüft jedes Bauteil in mehreren Hops (Alternativteil, Lieferant, Verfügbarkeit, Norm-Flag) und meldet nur die kritischen Positionen zurück. Pexon Consulting, 80 Mitarbeiter aus Deutschland, baut solche Agenten als 6-Wochen-Pilot direkt gegen euer ERP. In einem Projekt sank die manuelle Prüfzeit pro Stückliste von zwei Tagen auf unter zwei Stunden.
Das Problem: Die Stückliste sieht sauber aus, bis der Einkauf anfängt
Bei einem Hersteller komplexer elektromechanischer Produkte hatte eine Baugruppe rund 400 Positionen. Elektronik, Steckverbinder, Kabelkonfektion, mechanische Teile, Normteile. Auf dem Papier stimmte alles. In der Realität war jede dritte Freigabe verzögert, weil ein Bauteil abgekündigt war, ein Lieferant nicht liefern konnte oder ein Alternativteil fehlte, das keiner vorqualifiziert hatte.
Das ist kein Einzelfall. Elektronik-Lieferzeiten sind 2026 von routinemäßigen 8 bis 16 Wochen auf 26 bis 55 Wochen für die schwierigsten Kategorien gestiegen, Mikrocontroller liegen bei 30 bis 55 Wochen (GlobX, Electronic Component Lead Times 2026). Gleichzeitig ist die Obsoleszenz-Rate hoch: 2022 wurden über 750.000 Bauteile abgekündigt, und Komponenten halten im Schnitt nur noch zwei bis fünf Jahre bis zum EOL (Z2Data). Wer eine 400-Positionen-Stückliste manuell prüft, findet diese Fallen erst, wenn es teuer wird.
Der teure Teil ist nicht die Suche nach einem Bauteil. Der teure Teil ist der Multi-Hop: Bauteil X ist abgekündigt, also brauche ich ein Alternativteil, das aber muss form-fit-function-kompatibel sein, es muss einen lieferfähigen Lieferanten haben, und es darf keine Norm brechen, die für das Endprodukt gilt. Diese Kette denkt ein Mensch pro Position durch. Ein Agent macht das für alle 400 gleichzeitig.
Was ein BOM-Reasoning-Agent wirklich ist (und was nicht)
Ein BOM-Reasoning-Agent ist ein LLM-gesteuerter Agent, der über eine Stückliste reasoned und dabei mehrere Werkzeuge in Folge aufruft, statt eine einzelne Frage zu beantworten. Er ist kein Chatbot, der eine Teilenummer nachschlägt. Er ist ein Orchestrator, der pro Position eine Entscheidungskette durchläuft und nur die Positionen eskaliert, die ein Mensch wirklich ansehen muss.
Die vier Hops, die den Kern ausmachen:
- Bauteil-Status: Ist die Position aktiv, NRND (not recommended for new designs) oder abgekündigt? Datenquelle ist euer ERP plus Lifecycle-Daten.
- Alternativteil: Wenn kritisch, gibt es ein form-fit-function-kompatibles Alternativteil? AI-Cross-Reference-Tools wie Z2Data oder Lytica liefern hier Kandidaten mit Kompatibilitätsgrad.
- Lieferant und Verfügbarkeit: Welcher Lieferant führt das Teil oder die Alternative, und wie ist die aktuelle Lieferzeit? Das kommt live aus Distributor-APIs und eurem Lieferanten-Stammdatensatz.
- Norm- und Compliance-Flag: Verletzt die Alternative eine Norm, die für das Endprodukt gilt (RoHS, REACH, branchenspezifische Zulassung)? Dieser Hop verhindert, dass der Agent ein technisch passendes, aber regulatorisch verbotenes Teil vorschlägt.
Der Unterschied zu einer klassischen BOM-Software ist das Reasoning zwischen den Hops. Eine Regel-Engine kann „Teil abgekündigt, zeige Alternativen“ abbilden. Sie kann nicht entscheiden, ob die dritte Alternative trotz höherem Preis die richtige ist, weil die ersten beiden bei eurem gesperrten Lieferanten liegen. Genau diese kontextabhängige Abwägung ist der Grund, warum wir hier einen Agenten und keine starre Pipeline bauen.
So funktioniert die Orchestrierung technisch
Der Agent definiert pro Hop ein Tool und ruft diese Werkzeuge in einer Reasoning-Schleife auf. Wir nutzen dafür in aktuellen Projekten LangGraph (v1.0 GA seit Oktober 2025, rund 126.000 GitHub-Stars, Abruf Juli 2026) als Orchestrierungs-Layer und claude-sonnet-4-6 als Reasoning-Modell. Das Modell entscheidet, welches Tool als Nächstes dran ist, statt einer fest verdrahteten Reihenfolge.
Das folgende Beispiel zeigt die vier Tool-Definitionen und die Orchestrierung. Vereinfacht, aber lauffähig gegen echte Endpunkte:
# bom_agent_tools.py
# Vier Werkzeuge für den Multi-Hop: Status, Alternative, Lieferant, Norm
import httpx
ERP_BASE = "https://erp.internal/odata/v2" # OData-Endpunkt des ERP
DISTRIBUTOR_API = "https://api.distributor.example/v1"
def bauteil_status(teilenummer: str) -> dict:
"""Hop 1: Lifecycle-Status aus dem ERP holen (aktiv / NRND / EOL)."""
r = httpx.get(f"{ERP_BASE}/Parts('{teilenummer}')", timeout=10)
r.raise_for_status()
daten = r.json()
return {
"teilenummer": teilenummer,
"status": daten.get("LifecycleStatus", "unbekannt"),
"letzte_bestellung": daten.get("LastPurchaseDate"),
}
def finde_alternative(teilenummer: str) -> list[dict]:
"""Hop 2: Form-Fit-Function-Alternativen mit Kompatibilitätsgrad."""
r = httpx.get(f"{DISTRIBUTOR_API}/crossref/{teilenummer}", timeout=15)
r.raise_for_status()
# Nur Kandidaten mit hoher Kompatibilität zurückgeben
return [c for c in r.json()["candidates"] if c["fit_score"] >= 0.85]
def verfuegbarkeit(teilenummer: str) -> dict:
"""Hop 3: Lieferant und aktuelle Lieferzeit live abfragen."""
r = httpx.get(f"{DISTRIBUTOR_API}/availability/{teilenummer}", timeout=15)
r.raise_for_status()
d = r.json()
return {
"lieferant": d["preferred_supplier"],
"lieferzeit_wochen": d["lead_time_weeks"],
"auf_lager": d["in_stock"],
}
def norm_check(teilenummer: str, produkt_normen: list[str]) -> dict:
"""Hop 4: Verletzt das Teil eine Norm des Endprodukts (RoHS, REACH)?"""
r = httpx.get(f"{DISTRIBUTOR_API}/compliance/{teilenummer}", timeout=10)
r.raise_for_status()
zert = set(r.json()["certifications"])
fehlend = [n for n in produkt_normen if n not in zert]
return {"konform": len(fehlend) == 0, "fehlende_normen": fehlend}Die Orchestrierung verbindet die Tools mit dem Modell. Der Agent bekommt die Stückliste, iteriert über die Positionen und ruft pro Position genau die Hops auf, die nötig sind. Eine aktive Position mit lieferfähigem Lager braucht keinen Alternativ-Hop:
# bom_agent_orchestrierung.py
# Reasoning-Schleife: das Modell wählt den nächsten Hop selbst
import anthropic
import json
from bom_agent_tools import (
bauteil_status, finde_alternative, verfuegbarkeit, norm_check,
)
client = anthropic.Anthropic()
MODELL = "claude-sonnet-4-6"
# Tool-Schemas für das Modell (gekürzt: ein Tool exemplarisch)
TOOLS = [
{
"name": "bauteil_status",
"description": "Lifecycle-Status eines Bauteils aus dem ERP.",
"input_schema": {
"type": "object",
"properties": {"teilenummer": {"type": "string"}},
"required": ["teilenummer"],
},
},
# finde_alternative, verfuegbarkeit, norm_check analog definieren
]
DISPATCH = {
"bauteil_status": lambda a: bauteil_status(a["teilenummer"]),
"finde_alternative": lambda a: finde_alternative(a["teilenummer"]),
"verfuegbarkeit": lambda a: verfuegbarkeit(a["teilenummer"]),
"norm_check": lambda a: norm_check(a["teilenummer"], a["produkt_normen"]),
}
def pruefe_position(teilenummer: str, produkt_normen: list[str]) -> str:
"""Lässt das Modell die Hops für eine Position durchlaufen."""
nachrichten = [{
"role": "user",
"content": (
f"Prüfe Bauteil {teilenummer} für ein Produkt mit den Normen "
f"{produkt_normen}. Nutze die Tools und melde nur, ob die "
"Position kritisch ist und was zu tun ist."
),
}]
while True:
antwort = client.messages.create(
model=MODELL, max_tokens=1024, tools=TOOLS, messages=nachrichten,
)
if antwort.stop_reason != "tool_use":
# Modell ist fertig, gib das Fazit zurück
return "".join(b.text for b in antwort.content if b.type == "text")
nachrichten.append({"role": "assistant", "content": antwort.content})
ergebnisse = []
for block in antwort.content:
if block.type == "tool_use":
daten = DISPATCH[block.name](block.input)
ergebnisse.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": json.dumps(daten, ensure_ascii=False),
})
nachrichten.append({"role": "user", "content": ergebnisse})
if __name__ == "__main__":
print(pruefe_position("MC-4711", ["RoHS", "REACH"]))Der ERP-Zugriff läuft in Hop 1 über OData. In der Produktion setzen wir das nicht als direkte HTTP-Calls um, sondern über einen MCP-Server, der die OData-Entitäten als Tools exponiert. Das ist der Standard, den wir für ERP-Anbindung inzwischen durchgängig nutzen, mehr dazu unter unserem MCP-Server-Pattern für ERP-Anbindung.
Warum MCP der richtige Weg zum ERP ist
MCP ist 2026 zur Standard-Schnittstelle zwischen Agenten und ERP geworden, und das aus einem konkreten Grund: Statt für jeden Agenten eine eigene ERP-Integration zu schreiben, exponiert ein MCP-Server die Geschäftsobjekte einmal als Tools, die jeder Agent nutzt. Der von Anthropic Ende 2025 spezifizierte offene MCP-Standard wird inzwischen von Anthropic, OpenAI, Google DeepMind, Microsoft und hunderten Enterprise-Vendoren unterstützt (Internative, MCP Explained 2026).
Für SAP-Landschaften gibt es den offenen OData-MCP-Proxy, der jede OData-V2- oder REST-API in einen MCP-Server verwandelt und automatisch Tools für jedes Entity-Set generiert (SAP Community). Praktisch heißt das: Eure Parts-Entität aus dem ERP wird zum Tool bauteil_status, ohne dass jemand Glue-Code pflegt.
Unsere klare Empfehlung: Baut die ERP-Anbindung von Anfang an über MCP, nicht über direkte API-Calls im Agenten-Code. Direkte Calls funktionieren im POC, aber jeder neue Agent dupliziert dann die Integration, und bei einem ERP-Schema-Update müsst ihr zehn Stellen anfassen statt einer. Wer zwei Wochen POC gegen direkte OData-Calls baut und dann feststellt, dass drei weitere Agenten dieselben Daten brauchen, hat den teureren Weg gewählt.
Was der Agent bringt und was er kostet
Der messbare Effekt kommt aus der Parallelisierung. Eine 400-Positionen-Stückliste, die ein Einkäufer über zwei Tage prüft, läuft als Agenten-Batch in unter zwei Stunden durch, und der Mensch sieht danach nur die zehn bis fünfzehn kritischen Positionen. AI-BOM-Sourcing-Plattformen berichten von über 60 Prozent weniger administrativer Arbeit und Durchschnitts-Einsparungen von 12 Prozent oder mehr durch normalisierte Angebote (Mercantis, BOM Sourcing Automation 2026). Diese Zahlen decken sich mit dem, was wir in unseren Projekten sehen, sobald der Agent gegen echte Lieferanten-APIs läuft.
Der Aufwand für einen produktiven Piloten liegt bei uns bei sechs Wochen. In dieser Zeit binden wir euer ERP über MCP an, definieren die vier Hops gegen eure realen Datenquellen und testen den Agenten gegen einen Satz historischer Stücklisten, bei denen ihr das richtige Ergebnis schon kennt. Kein Big-Bang, sondern ein abgegrenzter Use-Case mit messbarem Vorher-Nachher.
Ein ehrlicher Punkt zur Datenqualität: Der Agent ist nur so gut wie euer Bauteil-Stammdatensatz. Wenn Lieferzeiten und Lifecycle-Status im ERP veraltet sind, reasoned der Agent auf falscher Basis. Deshalb ist der erste Hop im Piloten immer ein Daten-Audit. Das kostet Zeit, spart aber die Enttäuschung, dass ein technisch sauberer Agent auf Datenschrott läuft.
Worauf ihr bei der Umsetzung achten solltet
Vier Punkte entscheiden, ob der Agent im Produktivbetrieb trägt:
- Halluzinations-Schutz beim Alternativteil: Der Agent darf ein Alternativteil nur vorschlagen, wenn eine Datenquelle es als form-fit-function-kompatibel bestätigt. Nie aus dem Modellwissen heraus. Das erzwingt ihr über den Tool-Zwang, nicht über den Prompt.
- Norm-Hop ist nicht optional: Ein technisch passendes Teil, das eine RoHS- oder REACH-Anforderung bricht, ist ein teurer Fehler. Der Norm-Check muss ein hartes Gate sein, kein weicher Hinweis.
- Mensch im Loop bei Eskalation: Der Agent entscheidet nicht final. Er priorisiert und liefert Begründung plus Quelle. Die Freigabe eines Alternativteils bleibt beim Einkäufer.
- Idempotenz und Rate-Limits: Distributor-APIs haben harte Limits. Der Batch-Lauf über hunderte Positionen braucht Caching und Retry, sonst kippt er beim ersten großen ERP-Export.
Häufig gestellte Fragen
Was kostet ein BOM-Reasoning-Agent als Pilotprojekt?
Ein produktiver Pilot mit ERP-Anbindung, den vier Hops und Test gegen historische Stücklisten läuft bei uns über sechs Wochen. Die Investition liegt im Bereich, den ihr für einen abgegrenzten KI-Use-Case einplant, und amortisiert sich über die eingesparte Prüfzeit pro Stückliste. Die genaue Zahl hängt von der ERP-Komplexität und der Zahl der Datenquellen ab.
BOM-Reasoning-Agent oder klassische BOM-Software, was ist besser?
Kommt drauf an, aber für den Alternativteil-Fall ist der Agent überlegen. Klassische BOM-Software prüft nach festen Regeln und zeigt Alternativen an. Der Agent wägt kontextabhängig ab, welche Alternative bei eurem Lieferanten-Setup und euren Normen wirklich passt. Wer nur einen Obsoleszenz-Report braucht, kommt mit Standard-Software aus. Wer die Entscheidungskette automatisieren will, braucht das Reasoning.
Funktioniert das mit SAP oder nur mit modernen ERP-Systemen?
Es funktioniert mit SAP. Der offene OData-MCP-Proxy verwandelt jede SAP-OData-API in einen MCP-Server und generiert Tools für die Entity-Sets automatisch. Auch ältere ERP-Systeme lassen sich über ihre REST- oder OData-Schnittstellen anbinden. Entscheidend ist nicht das ERP-Alter, sondern ob die Stammdaten gepflegt sind.
Wie verhindert der Agent, dass er ein falsches Alternativteil vorschlägt?
Über Tool-Zwang. Der Agent darf ein Alternativteil nur nennen, wenn eine externe Datenquelle es mit einem Kompatibilitätsgrad bestätigt, und er muss danach den Norm-Check bestehen. Vorschläge aus reinem Modellwissen ohne Datenbeleg werden im Design unterbunden. Die finale Freigabe bleibt immer beim Einkäufer.
Wie lange dauert es, bis der Agent produktiv läuft?
Sechs Wochen für einen abgegrenzten Piloten. Woche eins ist ein Daten-Audit des Bauteil-Stammdatensatzes, danach folgen ERP-Anbindung über MCP, Aufbau der vier Hops und Test gegen historische Stücklisten mit bekanntem Ergebnis. Ein flächendeckender Rollout über alle Produktlinien dauert länger und hängt an eurer Datenqualität.
Nächster Schritt
Wenn ihr gerade evaluiert, ob sich ein agentischer Stücklisten-Check für eure Produkte lohnt, klärt das am schnellsten ein Blick auf eure realen Stücklisten und euer ERP-Setup.
Verwandte Themen
→SAP-Daten per Sprache abfragen mit Copilot Studio
→Unternehmens-Wissenssuche mit einem RAG-System aufbauen
