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.
