CAD-BOM = EBOM - Jörg was machst du?

Sind CAD-BOM and E-BOM das selbe?

Ich werde oft gefragt, ob CAD-BOM und E-BOM dasselbe sind. Diese Frage kommt besonders oft im Teamcenter-Umfeld vor und wird dort mit Leidenschaft, oft auch fast religiösem Eifer, diskutiert.

Hier das Video und ein paar Insights dazu:

Zunächst aus der Perspektive der reinen Lehre: Aus logistischer Sicht müssen im Produktentstehungsprozess die Materialien für die Produkte, d.h. die logistischen Entitäten, die im Unternehmen bewegt werden, definiert werden. Es gibt Materialien, die intern (Internal Design) und andere, die extern (External Design) definiert werden. Für intern definierte Materialien wird ein Dokument erstellt, das aus einem 3D-Modell und einer daraus abgeleiteten Zeichnung besteht. So entstehen zwei Strukturen: die CAD-BOM und die E-BOM (Detail A im Post-Bild).
Nun zur Praxis. Da das ein Thema ist was im Teamcenter Umfeld häufig ist am Beispiel von Teamcenter.
Dort gibt es das Item (Detail B im Bild), das Revisions hat. An diesen Revisions hängen Datasets, an diesen die Dokumente (Detail C im Bild).

Die Interpretation beginnt: Das Item könnte ein Material repräsentieren und das Dataset das Dokument. Beide Objekte und deren Lifecycle sind fest miteinander verbunden. Da nur Items in Teamcenter in eine nutzbare Struktur (BomViewRevisions/PSOccurrence) überführt werden können, ergibt sich nur eine Struktur. Aus der Teamcenter-Perspektive wären CAD-BOM und E-BOM demnach dasselbe.

Diese Ansicht wurde über Jahre propagiert und oft implementiert. Noch heute verteidigen viele Berater diesen Ansatz. Sie behaupten, es würde funktionieren.

Aber warum wurden dann im Teamcenter das CAD/Part Alignment und Designs und Parts als eigene Objekttypen eingeführt?

Aus meiner Sicht gibt es drei Gründe:

Das Item-Modell erfordert ein striktes 1:1 zwischen Dokument und Material. Entwickler (Detail A) fassen jedoch oft Parts in Dokumenten zusammen, die die Form-Fit-Function nicht erfüllen, wodurch das geforderte 1:1 bricht.

Die E-BOM enthält auch mechatronische Teile. Wären diese in der CAD-BOM, würde die CAD-Schnittstelle versuchen, die Dokumente dieser Teile auszulesen, was technische Probleme nach sich zieht.

Hinzu kommt, dass die Pflege der E-BOM und CAD-BOM oft von unterschiedlichen Personen durchgeführt wird. Um den Zugriff entsprechend zu regeln, sind zwei separate Strukturen hilfreich.

Es kann funktionieren, E-BOM und CAD-BOM zu vereinen, aber die impliziten Zwänge dieses Ansatzes können schwerwiegende Folgefehler verursachen, die downstream auftreten.

Was meint ihr dazu? Wie ist eure Erfahrung bei anderen PLM-Systemen?
Ich freue mich auf eure Kommentare. 📝

Mehr dazu in unserem Training: Methodical Essentials for PLM Experts (https://stz-rim.com/methodical-essent...)