CAD-zu-ERP-Stücklisten-Sync: die Kurzfassung
CAD-zu-ERP-Stücklisten-Sync bedeutet, die Stückliste (BOM) im Zustand wie konstruiert aus Siemens NX und Teamcenter ohne manuelle Neueingabe in die Struktur wie gefertigt Ihres ERP zu überführen. inteliScience baut diese Konnektoren auf NXOpen und dem Teamcenter-SAP-Gateway auf, mit menschlicher Validierung des Feld-Mappings. Richtig umgesetzt, entfallen so mehr als 780 verschwendete Engineering-Stunden pro Jahr.
| Manuelle Neueingabe | Automatisierte Synchronisation | |
|---|---|---|
| Wer tippt die Stückliste ins ERP ein | Ein Ingenieur, zweimal | Niemand |
| Wann das ERP eine Änderung sieht | Tage nach der Freigabe | Minuten nach Genehmigung des ECO |
| Typische Fehlerquelle | Kommafehler, veraltete Revisionen | Mapping-Regeln, einmal abgefangen |
| Zurückgewonnene Konstruktionszeit | Keine | ~3 Stunden pro Ingenieur und Woche |
Das Problem: Eine CAD-Stückliste war nie dafür gebaut, in Ihr ERP zu gelangen
Fragen Sie ein beliebiges Engineering-Team, wohin der Tag verschwindet, und jemand wird es erwähnen: Nachdem das Modell fertig ist, wird dieselbe Teileliste ein zweites Mal in SAP eingetippt. Eine unserer Umfragen zu CAD im Engineering brachte es unverblümt auf den Punkt: Die Leute wollen, dass KI “SAP-Prozesse wie die Stückliste automatisiert” und “Änderungsprotokolle im System führt, ohne dass manuell indexiert werden muss.” Das ist keine ausgefallene Forderung. Es ist die Bitte, das Kopieren von Zahlen zwischen zwei Fenstern zu beenden.
Der Grund für den Schmerz ist struktureller Natur. Eine CAD-Stückliste, manchmal auch Konstruktionsstückliste oder DBOM genannt, beschreibt das Produkt aus geometrischer Sicht: was mit was zusammenpasst, in welcher Baugruppe. Ihr ERP will etwas völlig anderes. Es will Beschaffungsdaten, Make-or-Buy-Kennzeichen, Maßeinheiten und eine Materialstammnummer, die kein CAD-System kennt.
Die CAD-Stückliste lässt sich also nicht einfach ins ERP “schieben”. Ihr fehlen Beschaffungsinformationen, ihre Metadaten passen nicht zu den ERP-Feldern, die Namenskonventionen driften zwischen beiden Systemen auseinander, und sie enthält oft Elemente (Referenzgeometrie, Schweißdarstellungen, Skelettteile), die das ERP nicht interpretieren kann. Jede einzelne dieser Lücken wird derzeit von einem Menschen geschlossen, der neu eintippt und erneut prüft. Dieser Mensch ist teuer und, an einem schlechten Freitag, fehlerhaft.
eBOM und mBOM sind nicht dieselbe Liste
Hier ist die Unterscheidung, die die meisten Projekte nach dem Motto “einfach die beiden Systeme verbinden” unterschätzen. Die Konstruktionsstückliste (eBOM) definiert das Produkt wie konstruiert. Die Fertigungsstückliste (mBOM) definiert es wie gefertigt, mit Phantom-Baugruppen, Verbrauchsmaterialien, Prozessschritten und werksspezifischen Substitutionen, die nie im Modell erscheinen.
Siemens’ eigene Empfehlung lautet, diese Strukturen entkoppelt zu halten: Die eBOM liegt in Teamcenter, die mBOM wird auf der ERP-Seite geplant, und eine kontrollierte Übergabe verbindet sie. In einem typischen Teamcenter-zu-SAP-Ablauf wird die EBOM als versionierte Struktur in Teamcenter erstellt und an SAP übergeben, wo der Fertigungsplaner sie in eine MBOM überführt. Die beiden sind verwandt, nicht identisch, und in der Transformation zwischen ihnen steckt die eigentliche Ingenieurarbeit.
Synchronisation ist also keine Kopie. Sie ist eine kontrollierte Übersetzung von einer Struktur in eine andere, mit Regeln dafür, was übernommen wird und was nachgelagert hinzukommt. Behandeln Sie sie als Kopie, und Sie kämpfen jahrelang mit doppelten Teilen und nicht zusammenpassenden Revisionen.
Drei Arten der Synchronisation – und die, die wir empfehlen
Es gibt drei ehrliche Muster, und sie sind nicht gleich gut.
- Jede CAD-Revision spiegeln. Jedes Speichern oder jede kleinere Revision wird ins ERP propagiert. Einfach umzusetzen und so voller Rauschen, dass Planer die Updates schon innerhalb eines Monats zu ignorieren beginnen. Wir raten davon ab, außer bei winzigen Katalogen.
- Selektive Propagierung. Nur als “Freigegeben” markierte Strukturen fließen durch. Sauberer und eine vernünftige Standardwahl für Teams ohne formales Änderungsmanagement.
- Änderungsauftragsgesteuert. Ein genehmigter Änderungsauftrag (ECO) ist der Auslöser. Das ERP-Update, das Gültigkeitsdatum und die Revisionshistorie hängen alle an einem einzigen kontrollierten Ereignis.
Unsere klare Empfehlung für jedes Team mit mehr als einer Handvoll Stücklisten ist das änderungsauftragsgesteuerte Muster. Es entspricht der Art, wie die Fertigung Änderungen tatsächlich aufnimmt – nach Gültigkeit statt nach CAD-Zeitstempel – und es gibt Auditoren einen einzigen Datensatz, dem sie folgen können. Selektive Propagierung ist der akzeptable Rückfall, während Sie ein Änderungsmanagement aufbauen. Vollständiges Spiegeln ist eine Falle, verkleidet als die einfache Option.
Wie die Automatisierung tatsächlich funktioniert
Die Mechanik ist weniger exotisch, als Anbieter sie klingen lassen. Sie lesen die freigegebene Struktur aus NX oder Teamcenter aus, transformieren sie anhand eines Mappings und schreiben sie beim oben gewählten Auslöser ins ERP.
Die Extraktion aus einer NX-Baugruppe ist ein kurzes NXOpen-Skript:
# Extract the released BOM from an NX assembly (NXOpen, Python)
import NXOpen
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
root = work_part.ComponentAssembly.RootComponent
rows = []
for child in root.GetChildren():
proto = child.Prototype.OwningPart
rows.append({
"part_number": child.DisplayName,
"quantity": 1, # duplicates get rolled up in the next step
"revision": proto.GetStringAttribute("Revision"),
})In der Transformation steckt die Disziplin. Sie definieren einmalig, wie jedes Engineering-Attribut auf ein ERP-Stammdatenfeld abgebildet wird, und lösen den Schreibvorgang erst dann aus, wenn der Änderungsauftrag genehmigt ist – niemals bei jedem CAD-Speichern.
# Map engineering attributes to ERP fields, push only on "Released"
FIELD_MAP = {
"part_number": "MATNR", # SAP material number
"quantity": "MENGE", # component quantity
"revision": "REVLV", # revision level
}
def to_erp(row):
return {FIELD_MAP[k]: v for k, v in row.items() if k in FIELD_MAP}
if change_order.status == "Released":
positions = [to_erp(r) for r in roll_up(rows)]
erp_client.upsert_bom(header=item, positions=positions)Bei SAP-Umgebungen läuft das meiste davon über das Teamcenter Gateway for SAP S/4HANA, den Konnektor, den Siemens und SAP gemeinsam entwickelt haben, ausgeliefert als SAP Integration Gateway Service im Teamcenter-2506-Release (Mitte 2025). Die Anbindung auf Socket-Ebene schreiben Sie dabei nur selten selbst. Was Sie aufbauen, sind das Mapping, die Trigger-Logik und die Fehlerbehandlung darum herum. Genau diese Arbeit lässt ein Standard-Gateway bei Ihnen liegen. Wenn Ihre Automatisierung auf individuellem NXOpen und Scripting basiert, ist unsere NX-Programmierung und Automatisierung die Schicht, die diese Extraktoren über NX-Upgrades hinweg am Leben hält.
Das läuft als POC. Was für die Produktion fehlt: Feld-Mapping-Governance, ECO-ausgelöste Gültigkeit, Behandlung von Revisionskonflikten, Validierung der SAP-Stammdaten, Monitoring und Rollback. Wir schließen die Lücke von “das Skript hat eine Stückliste auf meinem Laptop synchronisiert” zu “das gesamte Werk vertraut der ERP-Struktur”. Sehen Sie, wie wir NX-zu-ERP-Automatisierung liefern.
Was in der Produktion scheitert
Eine Demo synchronisiert eine saubere Baugruppe. Die Produktion scheitert an den unordentlichen 5%, und diese 5% sind die eigentliche Aufgabe.
Das Ziel sind nicht 100% Automatisierung. Es sind etwa 95% Automatisierung, wobei 5% bewusst der menschlichen Validierung vorbehalten bleiben – die Stellen, an denen ein Ingenieur eine Make-or-Buy-Entscheidung bestätigen oder einen Namenskonflikt auflösen muss. Die Fehler häufen sich an vorhersehbaren Stellen: Attribute, die in NX existieren, aber kein ERP-Feld haben, Teilenummern, die auf jeder Seite anderen Konventionen folgen, und Revisionen, die in falscher Reihenfolge eintreffen, wenn zwei Ingenieure in derselben Stunde freigeben.
Das Feld-Mapping ist der stille Killer. Eine Tabelle nach dem Muster “Engineering-Attribut zu ERP-Feld” über Tausende von Teiletypen hinweg von Hand zu pflegen, skaliert nicht und verfällt mit der Zeit. Dies ist einer der wenigen Fälle, in denen sich ein LLM wirklich auszahlt: Wir nutzen ein Sprachmodell zum Vorschlagen von Zuordnungen zwischen Engineering-Attributen und ERP-Stammdatenfeldern, woraufhin ein Ingenieur die Zuordnung einmal genehmigt und sie zur Regel wird. Die KI entwirft, der Mensch unterschreibt. So bleibt das von Ihren Ingenieuren geforderte Human-in-the-Loop-Prinzip erhalten, ohne sie zum Engpass zu machen. Wir nutzen dasselbe Muster in unserer gesamten Enterprise-KI-Integrationsarbeit: Die KI übernimmt den mühsamen ersten Durchgang, die Entscheidung liegt bei den Menschen.
Der andere zuverlässige Fehler besteht darin, die Synchronisation als Fire-and-Forget zu behandeln. Ohne Monitoring und einen Rollback-Pfad beschädigt ein fehlerhaftes Mapping stillschweigend Hunderte von Stücklistenzeilen, bevor es jemand bemerkt. Änderungsprotokolle und Gültigkeitsdatierung sind kein Papierkram; sie sind die Art, wie Sie einen Fehler rückgängig machen.
Kosten und Amortisation
Der finanzielle Fall ist ungewöhnlich klar, weil die manuelle Stücklisteneingabe einen messbaren Preis hat.
| Fehlerart (manuell) | Berichtete Kosten |
|---|---|
| Manuelle Stücklisteneingabe, 5 Ingenieure × 3h/Woche | 780 Stunden/Jahr, ~$39,000 an Gehalt |
| Veraltete Spezifikationen, die in die Fertigung gelangen | 200 Einheiten nachgearbeitet, ~$45,000 + 80h QC |
| Ein einziger Kommafehler | ~$23,000 an unbrauchbarem Material |
| Falsche Komponenten über globale Standorte hinweg | ~$67,000 falsch beschafft |
Diese Zahlen stammen aus branchenweiten Fallauswertungen von Stücklistenfehlern, nicht aus einem Marketing-Deck, und sie decken sich mit dem, was wir bei echten Übergaben sehen. Der Vorteil ist symmetrisch: Integrierte Abläufe verkürzen die Übergabe vom Engineering zur Fertigung häufig um rund 80%, mit Amortisation in etwa zwei Monaten für Teams mit mehr als 50 Stücklisten oder über 100 Änderungen pro Monat. Unterhalb dieses Volumens die ehrliche Antwort: Bringen Sie zuerst Ihre Namenskonventionen in Ordnung und kommen Sie später auf die Automatisierung zurück. Wir haben diese Art von Engineering-Automatisierung geliefert, bei der die Amortisation schnell war, und wir haben Teams auch schon gesagt, dass sie dafür noch zu klein sind.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einer eBOM und einer mBOM?
Die eBOM ist das Produkt wie konstruiert: die Struktur, die aus Siemens NX und Teamcenter kommt. Die mBOM ist das Produkt wie gefertigt, mit Prozessschritten, Verbrauchsmaterialien und werksspezifischen Positionen, die auf der ERP-Seite hinzukommen. Die Synchronisation verbindet sie; sie macht sie nicht identisch.
Können Sie eine CAD-Stückliste direkt in SAP oder ein anderes ERP schieben?
Nicht sauber. Einer CAD-Stückliste fehlen Beschaffungsdaten, sie verwendet eine Benennung, die selten zu den ERP-Feldern passt, und sie enthält Elemente, die das ERP nicht interpretieren kann. Sie brauchen eine Mapping-Schicht und einen Auslöser – genau das liefert die Automatisierung. Dass diese Schicht übersprungen wird, ist der Grund, warum so viele “direkte” Integrationen stillschweigend scheitern.
Wie viel kostet die CAD-zu-ERP-Stücklistenautomatisierung, und wann amortisiert sie sich?
Die Kosten hängen vom ERP, vom Konnektor und davon ab, wie unordentlich Ihre Teiledaten sind. Der Bezugspunkt, der die meisten Teams interessiert: Die Amortisation liegt bei etwa zwei Monaten, sobald Sie über rund 50 Stücklisten oder 100 Änderungen pro Monat kommen – gegenüber mehr als 780 Engineering-Stunden pro Jahr, die durch manuelle Eingabe verloren gehen. Unterhalb dieses Volumens rechtfertigen die Zahlen es meist noch nicht.
Sollten wir jede CAD-Revision synchronisieren oder nur freigegebene?
Nur freigegebene, und idealerweise nur bei einem genehmigten Änderungsauftrag. Das Spiegeln jeder Revision überflutet das ERP mit Rauschen, das Planer zu ignorieren lernen. Die änderungsauftragsgesteuerte Synchronisation entspricht der Art, wie die Fertigung Änderungen aufnimmt – nach Gültigkeitsdatum – und liefert Ihnen einen sauberen Audit-Trail.
Brauchen wir Teamcenter, oder können wir NX direkt mit dem ERP verbinden?
Sie können eine Stückliste mit NXOpen direkt aus NX extrahieren, und für kleine Betriebe reicht das. Aber ohne Teamcenter übernehmen Sie Revisionskontrolle, Gültigkeit und Änderungssteuerung selbst. Für die meisten Hersteller bedeutet der Weg von Teamcenter zum ERP weniger individuellen Code und weit weniger Risiko.
Nächster Schritt
Wenn die manuelle Neueingabe von Stücklisten die Woche Ihrer Ingenieure auffrisst, ist der schnellste Weg herauszufinden, ob sich Automatisierung auszahlt, ein kurzes Scoping-Gespräch: kein Produkt-Pitch, nur eine ehrliche Einschätzung Ihres Volumens und Ihrer Datenqualität.
Buchen Sie ein Strategiegespräch zu Ihrer CAD-zu-ERP-Übergabe
