Post 1
Welcome to BOM Hell – Is As Built = M(RP)-BOM and As Designed = EBOM? Let’s resolve the discourse 🤔
Kennt ihr das? Wenn euch die Berater die Namen für die BOMs um den Kopf wirbeln und ihr euch fragt, was denn jetzt was ist und wie ihr diese aufeinander beziehen könnt? 🧐
Nun, besonders beliebt sind folgende Kategorisierungen:
Kategorisierung: As Planned BOM, As Designed BOM, As Built BOM, As Delivered BOM
Kategorisierung: CAD-BOM, E-BOM, M-BOM, TOS, M(RP)-BOM…
Nun, was heißt das denn? Zuerst mal: Macht euch nicht die Mühe, beide Kategorisierungen zu mappen. Das geht zwar im Ansatz, zerbricht jedoch bei der tieferen Diskussion. Ich denke, das sind wie so oft Kategorisierungen desselben aus unterschiedlichen Perspektiven und in unterschiedlicher Schärfe.
Kategorisierung 1:
Die As … BOMs, fokussiert man auf einen definierten Zeitpunkt im Produktentstehungsprozess. Die Kategorisierung stellt dabei lediglich fest, dass diese BOMs zu unterschiedlichen Zeitpunkten unterschiedliche Inhalte haben. Das war’s schon. Wofür die BOMs genutzt werden, wer sie erstellt, wie ihre Semantik ist, welche Geschäftsobjekte sie tragen (Dokument, Part oder Material), ist nicht klar.
Kategorisierung 2:
Bei den xBOMs handelt es sich um benannte BOM‘s wobei versucht wird durch den ersten Buchstaben (z.B. E und M) den Bereich, in dem die BOMs genutzt werden zu bezeichnen. Auch diese Kategorisierung ist zu unscharf. Da sie aus der PLM-Welt kommt, fehlen spezifischen BOM’s aus dem ERP.
Um präzise zu sein versuche ich es mit einem Beispiel. Wir gehen von STO aus, abgebildet in Teamcenter und SAP.
Beim STO (Select to Order) haben wir einen Product Development Process. Zum SOP (Start of Production) muss eine M(RP)-BOM im ERP vorliegen. Diese entsteht über eine CAD-BOM im Teamcenter, geht über eine E-BOM-artige Part BOM im Teamcenter und wird dann als Dokumentenstruktur (besser so machen!) oder Konzernbom (kein Werk in der BOM im SAP abgegeben) ins SAP übergeben. Aus dieser entsteht eine werksspezifische M(RP)-BOM. Über den MRP-Lauf werden nun Fertigungsaufträge instanziiert. Diese haben eine Komponentenliste (auch eine BOM). Diese steuert die Lagerentnahme. GGf werden dort noch Teile ausgetauscht. In diesem Szenario wäre dann die Konzernbom soetwas wie die As-Designed, die M(RP)-BOM könnte man als beabsichtigt As-Built bezeichnen. Die Summe der Komponentenlisten aus den Fertigungsaufträgen eines Produkts wären nach der Disposition der Teile ein As Built. Diese wären auch gleichzeitig die As Delivered, da sich beim STO danach nichts mehr ändert.
Nun, ihr seht es ist leider so kompliziert. Daher besser die beiden Kategorien einfach getrennt lassen und sich merken, dass Kategorie 1 die As (…) BOMs im Wesentlichen für strenge ETO-Fälle geeignet sind.
Noch Fragen oder Anmerkungen? Ich freue mich auf eure Sicht.
📝 #PLM #ERP #Teamcenter #SAP #ProductLifecycle
Post 2
BOM Hell – the xBOM’s – I’m sure they say he’s crazy when I explain that.
Erinnert ihr euch an das Ein-Strukturen-Konzept, das über Jahre gepredigt wurde?
Eine BOM, warum brauchen wir mehr, haben die Kunden dann immer gefragt. Oft, wenn wir vom RIM das Mehrstrukturenkonzept in Workshops erläutert haben, hatten wir das Gefühl, die Teilnehmer glauben, die spinnen ein wenig.
Nun, das hat sich heute geändert. Ein wenig 😊. Es ist immer noch komisch.
Insbesondere dann, wenn wir unser RIM 360° Structure Model zeigen. Nun zumeist erklären wir es nicht vollständig, sondern nur Teile davon.
Doch heute will ich mal für euch unser RIM 360° Structure Model zeigen. Es ist unsere Referenz, welche Strukturen und Geschäftsobjekte Relevanz in Unternehmen haben.
Achtung, es ist nicht vollständig. Insbesondere Geschäftsobjekte aus Finance und Controlling fehlen noch komplett (das Slide war zu klein).
Ich dachte mir, ich erkläre die wesentlichen Aspekte davon in einer Reihe von Posts hier auf LinkedIn.
Zuerst jedoch einige allgemeine Erklärungen zum Bild.
Zu sehen sind die wesentlichen Geschäftsobjekte, die ein Unternehmensmodell braucht, und ihre Beziehungen. Diese Geschäftsobjekte sind in zwei prinzipielle Strukturarten geordnet.
Das sind zum Einen Strukturen, die nach dem Prinzip „Part of“ funktionieren. Also die klassischen BOM’s, die Teile eines Ganzen zusammenfassen. Diese sind in den schwarzen Rechtecken mit angedeuteter Struktur (runde Knoten) dargestellt.
Zum Anderen gibt es die klassifizierenden Strukturen. Diese funktionieren nach dem Prinzip „is a“. Diese sind ohne Rechtecke dargestellt.
Nun zu den Abkürzungen:
GPS: Generic Product Structure
PRES: Product Requirement Element Structure
FSES: Functional System Element Structure
PSES: Product System Element Structure
EBOM: Engineering Bill of Materials, manchmal auch Enterprise Bill of Materials
TOS: Technical Order Structure
M(RP)-BOM: Manufacturing Resources Planning Bill of Material (it’s MRP II 🙂
SBOM: Service BOM – I may change the Name here in the future
DTasD: Digital Twin as Delivered
DTasM: Digital Twin as Maintained
WBS: Work Breakdown Structure if using Project System
PM-Tasks: Project Management Tasks if using Project System
Wirklich etwas verrückt, das Ganze.
So nun, was meint ihr? Welche Strukturen fehlen? Wie benennt ihr die Strukturen?
Für welche Strukturen wäre euch eine tiefere Diskussion wichtig?
Nun ja, und wenn ihr ein auf euer Unternehmen zugeschnittenes Mehrstrukturenkonzept braucht, dann meldet euch heute noch beim STZ-RIM.