Hier findet Ihr eine Sammlung der Linkedin Posts von Prof. Fischer zum Thema Strukturtheorie
Strukturtheorie Lektion 1 – Instanzen in klassischen Produktstrukturen
Habt ihr schonmal über den #DigitalenZwilling gesprochen? Oder von varianten #Produktstruturen? Vielleicht ja auch von der mechatronischen Produktstruktur oder von der #MBOM. Nun vermutlich habt ihr auch schonmal über #KMAT im #SAP gesprochen und das man manchmal eine Materialvariante braucht. Die #Teamcenter Kenner unter euch kennen ggf. auch den Ausdruck Variant Item.
Nun, das klingt von den Worten schon alles sehr kompliziert.
Es wird leider noch schlimmer!
Das Problem ist, dass wir uns noch nicht hinreichend Gedanken darüber gemacht haben, was eigentlich der instanziierende Kontext in einer #Produktstruktur oder einer #Stückliste ist.
Da mein Forschungsgebiet die Strukturtheorie ist, hab ich das etwas aufgeschlüsselt. Hier in Kürze die Lektion 1 in Strukturtheorie – Instanzen in klassischen Produktstrukturen.
Bild Detail A – Eine Produktstruktur mit Lageinstanzen, die durch die Transformationsmatrix generiert werden. Hier muss man aufpassen, da es sich um relative Instanzen handelt, die nur zum nächst höheren Gruppe und nicht in Bezug auf den Kontext gelten.
Bild Detail B – Die abgeleitete Instanz für die Produktion bzw. den #MRP Lauf. Diese Instanz ermöglicht, die Baugruppe zu lagern. Eine klassische Ableitung aus der Produktstruktur, in der lediglich die Menge aggregiert wird.
Bild Detail C – Eine variantenbehaftete Struktur. Typischerweise eine, die als KMAT im SAP abgebildet werden kann (der Einfachheitshalber als Farbvariante dargestellt). Der Kopf der Struktur eignet sich nun nicht mehr zur Lagerhaltung. Diese Instanz funktioniert nur noch als Instanz zum Produktionsort unter der Voraussetzung, dass die Varianten am selben Produktionsort montiert werden und der Fertigungsauftrag für diesen instanziiert wird.
Bild Detail D – wieder die Instanzen der Variante zum Lagerort hin instanziiert. Falls ihr KMAT Strukturen habt, würdet ihr vermutlich eine Materialvariante verwenden. Falls ihr diese mit der Produktstruktur im Fall A in Verbindung bringen würdet, dann wäre das im Falle #Teamcenter eine Option dies über ein Variant Item zu lösen.
Vielleicht findet ihr das alles etwas kompliziert. Es ist nur die Lektion 1 – quasi für Anfänger.
Wenn wir das industrielle #metaverse erschaffen wollen, dann müssen wir dies dahinterliegende Grundproblematik lösen. Dann müssen wir in die Tiefe gehen.
#Strukturtheorie der Faculty of Mechanical Engineering & Mechatronics generiert hier die Antworten.
Unser Steinbeis – Transferzentrum Rechnereinsatz im Maschinenbau (STZ-RIM) stellt sie für unsere Kunden bereit.
und übrigens je mehr ich mich selbst damit beschäftige, desto mehr fallen mir die Lücken und weißen Flecken, die ich noch habe auf.
Strukturtheorie 2 – Grundlegende Abbildungsmechanismen von Strukturen in IT Systemen
Abbildungsmechanismen von Strukturen in IT Systemen
Eine entscheidende Frage bei der #PLM-Auswahl habt ihr diese berücksichtigt?
Wie werden eigentlich Produktstrukturen oder Stücklisten in IT-Systemen abgebildet? Die Strukturen sehen in den Strukturviewern immer ganz ähnlich aus. Die Mechanismen dahinter sind jedoch grundlegend verschieden. Abhängig von der Art der Abbildung werden Funktionen möglich oder durch das Objekt-Modell verhindert. Wenn Funktionen verhindert werden, kann man diese ggf. mit etwas oder viel Customizing hinmurksen. Wenn das Datenmodell es aber nicht trägt, sind die Auswirkung von solchen Entscheidungen über Jahrzehnte im Unternehmen negativ spürbar!
Wir schauen mal drauf:
- Ansatz A
- der häufig in PLM- und auch PIM-Systemen zu finden ist. Er geht davon aus, dass es nur die zu strukturierenden Objekt (ich nenne es verallgemeinert Information Entitiy) und Relationen zwischen diesen gibt. Die Bedeutung dieses Objektes könnte z.B. Part oder Dokument etc… sein.
- Ansatz B
- hier wird die Struktur mit mehr als nur den zu strukturierenden Objekten aufgebaut. Eine Information Entitiy wird nicht über eine Relation direkt mit einer anderen verbunden, sondern über ein gruppierendes Element (manchmal heißt dieses z.B. BomViewRevision oder Stücklistenkopf, der in der STKO steckt – wenn euch das nichts sagt, machts es nix :). Das gruppierende Element hat dann noch Positionsobjekt. Erst dieses sind dann mit den darunterliegenden zu strukturierenden Information Entities verbunden.
Nun ist die spannende Frage, welcher der Ansätze der bessere ist.
Vielleicht sind beide – je nach Anwendunsfall.
Wenn ihr Systemanbieter fragt, dann kennen diese meistens nur den einen in ihrem System und wissen nicht, welches Potenzial dieser hat und was er verhindert.
Wenn ihr euch klassische Beratungsunternehmen für die Systemauswahl holt dann definieren die vielleicht Use Cases und Funktionen.
Meine persönliche Erfahrung ist jedoch, dass diese nicht sagen können, welcher Ansatz wann besser ist ja mehr noch die Ansätze, die es gibt, gar nicht kennen.
Ihr seht – Strukturtheorie hilft
Wir vom #stzrim berücksichtigen auch die Auswirkungen des Objektmodells bei der PLM Auswahl. Warum? Weil wir wissen, wann welcher Ansatz der richtige ist und weil wir auch wissen, dass, wenn ein System gewählt und implementiert ist, die Vor- und Nachteile über Jahre wirken und sich tief in die Informationsarchitektur von Unternehmen einfressen.
Was meint ihr dazu?
RIM-Strukturtheorie 3 Instanziierungskontexte der Digitalisierung.
#SAP #KMAT vs. Materialvariante – #RIM-Strukturtheorie 3 Instanziierungskontexte der #Digitalisierung.
Ich glaube, wir alle denken zu wenig über Instanziierungskontexte der Digitalisierung nach – auch die Vendoren. Durch das fehlende Bewusstsein der Instanziierungskontexte werden dort draußen oft Informationsarchitekturen implementiert, die nicht passen und ewig Ärger machen. Von den unnötigen #Gemeinkosten, die diese erzeugen, ganz zu schweigen.
Was meine ich damit?
Eine Abbildung der Realität abstrahiert einen Teilaspekt dieser – sie verdichtet hin zu einem Kontext. Wenn der Kontext klar ist, dann ist auch der Zweck der Abbildung im System verstanden. Das klingt alles kryptisch – manche fragen sich vielleicht „Wovon redet der eigentlich?“
Nun die gute Nachricht – die dahinterstehende Theorie kann man bei uns im Steinbeis – Transferzentrum Rechnereinsatz im Maschinenbau (STZ-RIM) lernen. Dazu nutzen wir ganz anschauliche Beispiele.
Im Bild untern seht ihr das. Wir haben in einem Workshop das Thema KMAT vs. Materialvariante ad hoc mit dem, was auf dem Tisch stand, erklärt.
Ihr seht links im Bild eine leere Glasschüssel. Diese ist ein Arbeitsplatz in der Produktion. An diesem werden Süßigkeitentüten montiert. Es gibt 2x Varianten. Die Goldbärentüte und die Colaflaschentüte. Im #SAP #ERP könnte man das als KMAT abbilden und eine 150% #BOM daraus generieren. Sie würde aussehen wie im Bild (KMAT 4711). Über sie würde auch die Grundfunktion im #ERP nämlich der MRP Lauf durchgeführt werden können. Der Instanziierungskontext des KMAT ist der Produktionsort. Da beide Varianten am selben Ort montiert werden, können sie zusammengefasst werden. Dem aus dem #MRP -Lauf erzeugte #Fertigungsauftrag (eigentlich erst #Planauftrag) reich ein Bezug zum Produktionsort. Die #Variante, die gebildet wird, ist dann Bestandteil des FAUF (zu sehen am kleinen schwarzen Kasten auf dem FAUF).
Ist es nun der Wunsch, die Produkte auf #Lager zu legen, brauchen wir jeweils eine #Materialvarianten (4712 und 4713 rechts im Bild). Materialvarianten müssen sortenrein sein. Das liegt u.A. daran, dass alles, was auf einem Lagerplatz zusammengefasst ist, dem Prinzip 100% Austauschbarkeit unterliegen muss (form-fit-funktion Prinzip).
Zusammengefasst bedeutet das, dass ein KMAT im Produktionsorstbezug, wohingegen eine Materialvariante im Lagerortsbezug instanziiert ist.
Es gibt sehr viele weitere Instanziierungskontexte. Welche fallen euch ein und wie sind diese in den Systemen abgebildet?
Oberklassen der Strukturarten im PLM und ERP
#PLM und #ERP Systeme enthalten heute ganz unterschiedlichen Strukturarten. In der aktuellen industriellen Diskussion um #Digitalisierung wird dabei den Unternehmen zunehmend bewusst, dass es notwendig ist, diese Strukturarten gezielt zu explizieren und zu gestalten.
Dies ist auch ein zentraler Schlüssel zur echten #prozessautomatisierung, da automatisierte (Geschäfts-)Prozesse dann ins Leere laufen, wenn sie in ihrer Granularität auf eine andere Stufe springen und diese nicht sauber in einer Struktur expliziert ist.
Klingt alles abstrakt? – Ist es auch.
Versteh keiner!
Ja klar, weil sich noch kaum einer mit dieser Problematik beschäftigt.
Dieses Wissen ist jedoch einer der zentralen Schlüssel zur Geschäftsprozessdigitalisierung.
In meinem Video aus der Reihe Basics for #Digitalization erkläre ich, welche Klassen von Strukturarten im Unternehmen existieren und wie diese funktionieren.
Wenn ihr wissen wollt wie die Zusammenhänge zur echten (Geschäfts-)Prozesseautomatisierung jenseits von etwas dünnen Schlagworten wie Robotic Process Automation #RPA sind, dann meldet euch gerne unter info@stzrim.com.
Viel Spaß und viele Grüße
Hier das Video
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
🔍 Strukturtheorie – Sind PDM und CAD-nahe Strukturkonzepte geeignet für EBOM und MBOM?
Heute möchte ich mich einer Frage widmen, die mir ein wenig ketzerisch vorkommt. Dennoch beschäftigt sie mich seit einiger Zeit intensiv.
In einer Reihe von Posts zum Thema Strukturtheorie werde ich meinen „Best So Far Stand“ zur Frage teilen. 📌 Ihr findet alle meine Beiträge zum Thema Strukturtheorie hier: https://stz-rim.com/strukturtheorie/
Die Frage lautet: „Sind PDM und CAD-nahe Strukturkonzepte geeignet für EBOM und MBOM?“
Die meisten PLM-Systeme, insbesondere jene der großen Anbieter, die auch CAD-Systeme im Portfolio haben, stammen aus dem CAD-Datenmanagement und PDM. Ihre Strukturkonzepte sind primär auf CAD-Datenmanagement ausgelegt. Diese Strukturkonzepte werden heute auch zur Abbildung von E-BOMs und MBOs in diesen PLM-Systemen verwendet. Doch bisher wurde kaum diskutiert, ob sie dafür wirklich geeignet sind.
Ich war ursprünglich der Meinung, dass dies problemlos funktionieren würde. Doch je tiefer ich in die Themen ERP und ERP-nahes PLM eintauche, desto mehr beginne ich zu reflektieren.
Um dem Thema gerecht zu werden, ist es notwendig, sich intensiver mit den Strukturkonzepten im PDM auseinanderzusetzen. Ein erster kurzer Einblick dazu in diesem Post: Ihr seht im Bild die CAx-nahe Struktur (Detail A). Im Wesentlichen unterscheiden sich solche Strukturen von BOMs in zwei wesentlichen Punkten: Sie sind revisionsbehaftet (eine BOM wird durch Effektivitäten gesteuert) und prägen die Lageinstanzen der Bauteile aus (Bild – Detail B). Dies ist bei einer BOM nicht erforderlich. Hier können mehrfach verwendete Teile in einer Anwendung zusammengefasst werden (Bild – Detail C).
Die genannten Unterschiede erfordern einige komplexe Strukturkonzepte, die zur Abbildung von EBOM und MBOM eigentlich nicht notwendig wären. Doch sind sie störend? Und wenn ja, in welchem Maße? Das werde ich im nächsten Post untersuchen, in dem ich tiefer in die PDM-Datenmodelle eintauche.
🤔 Nun zu euch: Wie seht ihr die Situation? Gab es bei euch schon Diskussionen dazu? Wenn ja, wie waren eure Erfahrungen?
Ich freue mich auf eure Kommentare und Gedanken! 💬👇
PLM & ERP wachsen zusammen – höchste zeit ein paar Haudegen zusammentrommeln um neue Einordnungen, Kategorien und Prinzipien zu diskutieren.
Wo würde das besser gehen als in Karlsruhe, seit alters her einer der Geburts- und Hauptstätte des PLM.
Die Notwendigkeit einer Neujustierens der bisherigen noch vom PDM geprägte Strukturkonzepte und Datenmodelle kristallisiert sich heraus. Wie werden, wie sollte diese aussehen?
Dienstag saßen wir dafür mit xxx zusammen um die Themen als unseren unterschiedlichen Perspektiven für uns zu strukturieren. Die Diskussion war sehr vielschichtig und klasse.
Anbei einige Takeaways aus meiner Perspektive. Im Bild unten auch grafisch aufgezeigt.
Es kristallisieren sich immer deutlicher 3 Layer (nicht im IT-technischen Sinne) des PLM heraus. Das sind:
- 1-Application near Team Data Managment (TDM) Layer
dessen Aufgabe ist es die proprietären Datenmodelle der entwicklungsnahen Applikationen zu managen. Dazu gehören z.B. klassisches CAD, ECAD, CAE, ALM Werkzeuge etc. Die sind darauf optimiert die Datenmodelle der Applikationen zu verwalten. - 2-multistructure PLM-Layer
PLM bedeutet die Reifeentwicklung der produktrelevanten Daten hin zur M(RP) fähigen BOM mit der das Produkt produziert werden kann zu steuern. Dazu bedarf es einer Reihe von Strukturen z.B. Anforderungsstruktur, System/Funktionsstruktur, Bauraumstruktur, EBOM (you name it). Aufgabe diese Layers ist es die Versorgungspfade der Informationen über diese Strukturen zu managen und dafür zur sorgen dass immer die zeitrichtigen Informationen für die Folgeprozesse zur Verfügung stehen. - 3-ERP near PLM-Layer
Hinentwicklung der PLM Informationen zur lokalen Verwendbarkeit Herzstück des MRP-Laufs. Stabilisierung von F3 (Form Fit Function), durchführung des Supply Chain nahen Industiral Engineering, Management von local Content und local Customization, Ergänzung von Dispositionsstufen für Controlling, lokale Produktionsplanung und Steuerung, operativen Make or Buy, Beistellung etc.
Spannend ist meine/unsere Einschätzung der Vendoren.
Da sind die klassischen Vendoren die CAx-Systeme im Portfolio haben. Sie kommen von 1 fokussieren noch immer auf 1 und versuchen die dort entstandenen Strukturkonzepte und Datenmodelle auf 2 zu übertragen.
Neue oder flexible Vendoren. Sie haben kein CAx im Bauch und positionieren sich in Ebene 2. Durch geschickte low Code nahe Ansätze lassen sich ihre Datenmodelle in 1 erweitern. Die positionierung dieser in 3 wird man sehen
Zuletzt noch die großen ERP Anbieter – allen voran SAP. 3 wurde schon immer ERP nah durchgeführt. Sie haben Lösungen die von 3 kommend das Layer 2 auch abdecken und sogar ins Layer 1 hinaufreichen.
Es wird spannende wie es sich entwickeln wird. Ich denke diejenigen die Layer 3 zuerst durchdringen, erklären können und mit 1 und 2 in Verbindung bringen sind in der pool position.
Was meint ihr dazu?
Structure Theory 📘 – Zwei der wichtigsten Erkenntnisse im PLM, die wir übersehen haben.
Heute möchte ich mich im Rahmen meiner Post-Reihe zur Strukturtheorie (alle Posts dazu findet ihr hier: https://stz-rim.com/strukturtheorie/) mit zwei der wichtigsten Erkenntnisse im PLM beschäftigen. Das ist natürlich aus meiner Perspektive – ich freue mich auf Kommentare! 💬
Die Erkenntnisse sind: 1️⃣ Es gibt 3 PLM Layer unterhalb derer, die wir bisher diskutiert haben. 2️⃣ Es gibt zwei Arten von Strukturen, die wir gemeinhin als MBOM bezeichnen. Das ist die M(CAD)-BOM und die M(RP)BOM.
Beide Erkenntnisse hängen zusammen. Nun zur Erläuterung 🧐:
Erkenntnis 1️⃣: Es gibt 3 PLM Layer (hierzu auch der Post: Post zu den Layern)
🔸 Layer 1 – Application near Team Data Management (TDM) Layer: Management der proprietären Datenmodelle von Applikationen wie z.B. klassisches CAD, ECAD, CAE, ALM-Werkzeuge etc. Dieses Layer ist bekannt und auch im VDA-Modell so etabliert.
🔸 Layer 2 – Multistructure PLM-Layer (oder was wir als klassisches PLM verstehen): Dies hat die Aufgabe, die Reifeentwicklung der produktrelevanten Daten zu managen. Das Ergebnis des Layer 2 ist die Konzernstückliste (meist EBOM) oder aber eine generische M(RP)BOM.
🔸 Layer 3 – ERP near PLM-Layer: Hier geht es um die Entwicklung der in Layer 2 erzeugten M(RP)-BOM.
Mit den Layern hängt auch die Erkenntnis 2️⃣ zusammen. Beide Strukturen, die wir als MBOM bezeichnen, sind unterschiedlich in ihren Strukturstufen und Elementen auf der Blattebene.
Warum also haben wir das nicht früher erkannt?
Ganz einfach: Die M(RP)BOM entsteht in Schicht 3. Ihre Erstellung ist oft im ERP versteckt und wird nicht bemerkt. Für die Entwicklung spielt das keine Rolle mehr. Wir haben das Industrial Engineering über Lean Management wegdiskutiert; es gibt also in der Regel keine eigenen Abteilungen mehr dafür, und alles geschieht auf Zuruf.
Und warum sind diese Erkenntnisse so entscheidend?
Für die M(CAD)-BOM brauchen wir CAD-zentrierte Strukturen. Sie lassen sich mit klassischen PDM-Mechanismen effizient realisieren. Aber die M(RP)-BOM und auch die EBOM folgen ganz anderen Strukturprinzipien.
Wie sehen Sie das? Mehr dazu in den nächsten Beiträgen zum Thema.
Structure Theory – Sind PDM und CAD nahe Strukturkonzepte geeignet für EBOM und MBOM?
Wir gehen der Sache auf den Grund. Ihr seid hier richtig, wenn ihr schon immer wissen wolltet, wie PLM Datenmodelle in der Tiefe funktionieren und warum sich hier recht komplexe Mechanismen ergeben. (Alle meine Posts zum Thema hier: https://stz-rim.com/strukturtheorie/)
Lasst uns auf PDM Datenmodelle schauen. Zur Erklärung nutze ich ein verallgemeinertes Modell, das angelehnt an das Teamcenter Datenmodell ist 😊.
PDM Datenmodelle haben im Kern zwei Grundprinzipien:
- Prinzip 1: Revisionen und Laderegeln (Lifecycle Management)
- Prinzip 2: Occurrence Pfade mit Lageinformationen (Transformationsmatrix). Dadurch wird eine relative Instanz zur Lage gebildet.
- Zu Prinzip 1, Revisionen: Im Detail A auf dem Bild ist Item 4712 und seine Revisionen A, B und C. A und B haben bereits einen Freigabestatus (noch langweilen sich die PLM Experten 😉). Um die Struktur anzuzeigen, wird eine Revisionsregel benötigt (Bild, Detail B). Diese bestimmt, welche Revision der Struktur geladen wird (z.B. Working, Status, Präzise, Unpräzise etc.). Großer Vorteil des Ansatzes der Revisionsregeln ist es, dass beim Anlegen einer neuen Revision auf tieferer Ebene nicht die komplette Struktur nach oben revisioniert werden muss.
- Zu Prinzip 2, Occurrence Pfade bzw. relative Instanzen: Jedes CAD Modell hat eine Lage im Raum, die über eine Transformationsmatrix abgebildet wird. In den nativen CAD-Daten sitzt diese in dem jeweiligen Parent Assembly. Im PDM-Datenmodell (abhängig vom PLM System) wird diese ausgelesen und auf die sogenannte Occurrence geschrieben (Bild, Detail C). Daraus ergibt sich ein Occurrence Path (Bild, Detail D). Damit wird es möglich, dasselbe 3D-Modell in unterschiedlichen Lagen im CAD darzustellen (Item 4712 könnte mit unterschiedlichen Transformationsmatrizen mehrfach unter 4711 hängen, Bild Detail E).
Nun wird es eigentlich interessant.
Eine Occurrence instanziiert ein Item relativ zu seinem nächsthöheren Eltern-Item (4712 ist also relative Instanz zu 4711). Warum relativ? Würde 4711 unter einem anderen Item als 0815 hängen (z.B. 0816 – nicht dargestellt) und wir Veränderungen in der Lage von 4712 zu 4711 vornehmen, dann würde diese sich sowohl im Kontext 0815 als auch 0816 ändern.
Um eine Instanz zum Kontext (Item 0815) aufzubauen ist dann ein Apperanth Path (auch Absolut Occurrence) notwendig. Er instanziiert dann das Item zum Kontext. Man kann sich diesen Vorstellen wie ein Faden der die Occurrences aufsammelt.
Nun, das Modell ist kompliziert! Das ergibt sich aus dem Wunsch, dass Revisionen flexibel geladen werden können, die Lageinstanzen als Occurrence Path ausgelesen und Instanzen zum Kontext notwendig sind.
Meiner Meinung nach sind derartige Modelle für PDM Best Practice!
Sind sie es auch für EBOMs und/oder Technical Order Structure (TOS)? Insbesondere wenn man bedenkt, dass EBOM und TOS revisionslose Elemente (Material enthalten) und keine Transformationsmatrizen in der Struktur brauchen.
Nun, was meint ihr dazu?
Falls Teamcenterspezialisten unter euch sind, gerne auch das Modell präzisieren.
🔗 Structure Theory – Why EBOM’s are Revision-Free! 🚫🔄
Im letzten Post zum Thema Strukturtheorie habe ich argumentiert, dass die Datenmodelle der PDM-Systeme der meisten CAD-Vendoren durch ihre Anpassung für CAD etwas zu mächtig und etwas überfrachtet für EBOMs und MBOMs sind.
Das liegt daran das CAD-BOM Strukturen Revisionsmechanismen brauchen und darüber hinaus auch noch die CAD- Dateien Lagerichtig darstellen müssen (siehe post Post 8)
🏗️💻 Man kann sich das so vorstellen: Es ist, als würde man mit einem LKW auf eine Geschäftsreise gehen. Geht grundsätzlich, aber die Verhältnismäßigkeit scheint unpassend. 🚛➡️🏢
In diesem Post beginne ich mit der Herleitung, warum EBOMs revision-free sind. Dies ist dann die Voraussetzung für die Formulierung der Anforderungen an Datenmodelle zukünftiger PLM-Systeme. 🔄🚫 Wie immer repräsentiert dies meinen aktuellen „best so far“ Standpunkt. Ich lasse mich gerne vom Gegenteil überzeugen. 🧠💬
Der Schlüssel zu allem ist Form Fit Function! 🗝️💡 Bzw., das Verständnis, welches Geschäftsobjekt durch den Form Fit Function-Korridor läuft. Das ist natürlich das Design bzw. die Zeichnung der CAD-BOM. Sie hat dann eine 1:1 Beziehung zu einem virtuellen Material, das in der EBOM ist. Aus diesem werden dann ein oder mehrere echte globale Materialien geboren. 🌐🔄
Oft wird nun gefordert, dass das Material eine Revision haben soll. Nun, es unterliegt einem Änderungsdienst, der zeitliche Veränderungen von Attributen mitschreibt, aber eben keinem Revisionsmechanismus. Dass das geht, setzt voraus, dass sich die Designs strikt im F3-Korridor bewegen und die Entwicklung dafür sorgt. ⏰🔄
Hier beginnt jedoch das Problem. Die Entwickler haben wenig Zeit und sind manchmal ein wenig faul. Sie neigen daher dazu, ähnliche Teile in einem Design zusammenzufassen. Die CAD-Systeme und ihre Automatisierungsmechanismen unterstützen dies auch noch! 🔄🛠️
Geschieht das, dann folgt das Design nicht mehr dem F3 und verlässt den F3-Korridor. Daraus entstehen auch die oft gehörten Forderungen, Revisionen auf dem Material in der EBOM zu haben. 🚫🛑
Die einfache Lösung: Haltet euch an F3 beim Design, und die EBOM ist revisionfrei! ✔️🚫
Warum nun das virtuelle Material in der EBOM manchmal mehrere Materialnummern gebiert, im nächsten Post. 🤔❓
Ich bin gespannt, was ihr dazu meint, und freue mich auf eure Kommentare oder auch auf eure Fragen. 📢❓
🔍 Structure Theory – Revealing the Secrets 🚀 – Why Classic M-BOM and M(RP)-BOM are Different Things 💡
In dem heutigen Post zum Thema Strukturtheorie möchte ich tiefer in die Geheimnisse der classic MBOM 📈 und der M(RP)-BOM eintauchen.
Nun zu den ersten Fragen, die ihr euch bestimmt stellt. Es gibt doch nur die MBOM, oder? Sie ist doch lediglich eine Struktur in Montageorientierung. Nun, beides stimmt leider nicht.
Das, was wir heute als MBOM bezeichnen und was mit der M(RP)-BOM oft verwechselt wird, ist ein Ansatz aus der Digitalen Fabrik 🌐, der damals ungefähr zeitgleich bei Tecnomatix und Delmia entwickelt wurde. Dieser wurde von den PLM-Herstellern dann in ihre PLM-Systeme implementiert. Ursprüngliches Ziel dieses Ansatzes war es, die Montagereihenfolge zu planen und die Montageschritte mit 3D-Daten visualisierbar zu machen.
Die klassische Denkweise war es (siehe Bild oben: E-BOM zu M-BOM), die Entitäten der Unterstruktur der MBOM so neu zu sortieren, dass sie der Montagereihenfolge entsprechen. Dabei bildet demnach die Oberstruktur die einzelnen Montagestationen nach.
Mit dem Zusammenrücken der PLM und ERP-Systeme kam nun eine Verwechslung auf, der ich früher auch aufgesessen bin. Wir dachten, die MBOM sei die M(RP)-BOM.
Was ist nun die M(RP)-BOM? Sie ist diejenige BOM, über die der Manufacturing Resources Planning (MRP II)-Lauf durchgeführt wird. Sie unterscheidet sich in grundlegenden Punkten von der MBOM!
Die Oberstruktur der M(RP)-BOM enthält Dispositionsstufen. Das bedeutet, dass es die Stufen sind, durch die wir die Produktion mit Fertigungsaufträgen versorgen. Oft werden sie auch genutzt, um Intercompanyprozesse oder Controllingprozesse abzudecken.
Dennoch, die Oberstruktur der M(RP)-BOM und der MBOM könnte man mit einigen Kompromissen angleichen. Der wirkliche Unterschied liegt in der Unterstruktur!
In der Unterstruktur wird die M(RP)-BOM um Rohmaterial ergänzt, das dann auch in unterschiedlichen Werken unterschiedliche Ausprägungen hat. Das eigentliche Thema sind aber die M(RP)-BOM Snippets (Film). Durch diese werden regelmäßig Materialnummern komplett ausgetauscht, unter anderem um Form Fit Function zu stabilisieren, Local Content abzubilden, die Supplier-Wahl genau zu steuern, Beistellungsgruppen zu bilden, operational Make or Buy zu unterstützen und nicht zuletzt Dispositionsstufen zur Veredelung hinzuzufügen.
Nun, so ist es eben. Wenn ich das heute diskutiere, dann werden die Unterschiede oft von PLM-Beratern, aber auch von ERP-Beratern wegdiskutiert. Sie argumentieren dann, sie hätten das schon oft mit der classic MBOM implementiert und es würde funktionieren.
Der Grund dafür ist ganz einfach. Die Ergänzungsarbeiten in der M(RP)-BOM werden heute Downstream von den Feen und Helden im Industrial Engineering, in den Werken oder direkt in der Produktion erledigt. Sie sind nicht sichtbar, sie haben keine Lobby, oft ist nicht einmal bekannt, dass es sie gibt.
Mit dem Zusammenrücken von PLM und ERP werden sie zunehmend sichtbar. Und ich sage voraus, dass wenn wir erst Resilienz und Sustainability implementieren wollen, dass wir dann dringend die M(RP)-BOM im ERP-nahen PLM managen können müssen.
Wenn ihr wissen wollt, wie man das implementiert und warum das so zentral ist, fragt gerne uns vom RIM. 🤝
#StructureTheory #MBOM #MRPBOM #DigitalFactory #PLM #ERP #Innovation #Manufacturing #IndustrialEngineering #Sustainability #Resilience
Are CAD-BOM and E-BOM the same? 🤔 – Structure Theory: Revealing the Secrets 🔍
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 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
2 Antworten
Dear profesor and all staff. I am very grateful for this blog. As a company that is implementing SAP and Teamcenter in paralel, I found your principles the best guide for moving forward. I can’t tell you how many articles I read that start with ‚vision‘ and such sales terms… One thing I am looking forward to is subtitles for your youtube videos in English. Best regards
Dear Luka, thank you very much for taking the time to comment on our blog. We are pleased that you find our approaches helpful. We will pay even more attention to providing English content in the future. The entire YouTube playlist „Jörg, what are you doing?“ already has English subtitles and most of Prof. Dr. Jörg W. Fischer’s posts on LinkedIn are in English.