Here you can find a collection of Linkedin posts by Prof. Fischer on the topic of structural theory
Structural theory Lesson 1 - Instances in classic product structures
Have you ever thought about the #DigitalTwin spoken? Or from variants #Product strutures? Maybe also from the mechatronic product structure or from the #MBOM. Well probably you have also ever thought about #KMAT at #SAP spoken and that sometimes you need a material variant. The #Teamcenter Connoisseurs among you may also know the term Variant Item.
Well, that all sounds very complicated from the words themselves.
I'm afraid it gets worse!
The problem is that we have not yet given sufficient thought to what is actually the instantiating context in a #Product structure or a #Sparts list is.
Since my research area is structure theory, I broke it down a bit. Here in short the lesson 1 in structure theory - instances in classical product structures.
Image detail A - A product structure with layer instances generated by the transformation matrix. Here one must be careful, because these are relative instances, which are valid only to the next higher group and not in relation to the context.
Image detail B - The derived instance for the production or the #MRP Run. This instance allows to store the assembly. A classic derivation from the product structure, in which only the quantity is aggregated.
Image detail C - A variant structure. Typically one that can be mapped as a KMAT in SAP (shown as a color variant for simplicity). The header of the structure is now no longer suitable for warehousing. This instance now only works as an instance to the production location under the condition that the variants are assembled at the same production location and the production order is instantiated for it.
Image detail D - again instantiates the instances of the variant towards the storage location. If you have KMAT structures, you would probably use a material variant. If you would associate this with the product structure in case A, then that would be in case #Teamcenter an option to solve this using a Variant Item.
You may find this all a bit complicated. It's only lesson 1 - for beginners, so to speak.
When we look at the industrial #metaverse If we want to create a new world, then we have to solve the underlying problem. Then we have to go into the depths.
#Structure theory the Faculty of Mechanical Engineering & Mechatronics generates here the answers.
Our Steinbeis - Transfer Center Computer Application in Mechanical Engineering (STZ-RIM) provides them for our customers.
and by the way the more I look into it myself, the more I notice the gaps and white spots I still have.
Structural theory 2 - Basic mapping mechanisms of structures in IT systems
Mapping mechanisms of structures in IT systems
A crucial question in the #PLM-Have you taken them into account in your selection?
How are product structures or bills of materials actually mapped in IT systems? The structures always look quite similar in the structure viewers. However, the mechanisms behind them are fundamentally different. Depending on the type of mapping, functions are made possible or prevented by the object model. If functions are prevented, they can be muddled through with a little or a lot of customizing. But if the data model does not support it, the effects of such decisions will be felt negatively in the company for decades!
We'll take a look at it:
- Approach A
- which is often found in PLM and also PIM systems. It assumes that there are only the object to be structured (I call it generalized Information Entitiy) and relations between them. The meaning of this object could be e.g. Part or Document etc....
- Approach B
- here the structure is built with more than just the objects to be structured. An Information Entity is not directly connected to another via a relation, but via a grouping element (sometimes this is called e.g. BomViewRevision or BOM header, which is in the STKO - if that doesn't mean anything to you, it doesn't matter :). The grouping element then still has position object. Only these are then connected with the underlying information entities to be structured.
Now the exciting question is which of the approaches is the better one.
Maybe both - depending on the application.
If you ask system providers, they usually only know the one in their system and don't know what potential it has and what it prevents.
If you get classic consulting companies for the system selection, then they might define use cases and functions.
However, my personal experience is that they cannot say which approach is better and when, and are even more unaware of the approaches that exist.
You see - structural theory helps
We from the #stzrim also consider the impact of the object model in PLM selection. Why? Because we know when which approach is the right one and because we also know that once a system is selected and implemented, the advantages and disadvantages have an impact for years and eat deeply into the information architecture of companies.
What do you think?
RIM structural theory 3 instantiation contexts of digitization.
#SAP #KMAT vs. material variant - #RIM structural theory 3 instantiation contexts of #Digitization.
I think we all think too little about instantiation contexts of digitization - even the vendors. The lack of awareness of instantiation contexts means that information architectures are often implemented out there that don't fit and are forever causing trouble. Not to mention the unnecessary # overhead these generate.
What do I mean by that?
A representation of reality abstracts a partial aspect of it - it condenses it into a context. If the context is clear, then the purpose of the mapping in the system is also understood. This all sounds cryptic - some may wonder "What is he talking about?"
Now the good news - you can learn the theory behind it at the Steinbeis Transfer Center for Computer Applications in Mechanical Engineering (STZ-RIM). We use very clear examples for this purpose.
You can see this in the picture below. We explained in a workshop the topic KMAT vs. material variant ad hoc with what was on the table.
You can see an empty glass bowl on the left of the picture. This is a workstation in production. Candy bags are mounted on it. There are 2x variants. The golden bear bag and the cola bottle bag. In the #SAP #ERP you could map this as a KMAT and generate a 150% #BOM from it. It would look like in the picture (KMAT 4711). The basic function in #ERP, i.e. the MRP run, could also be executed via it. The instantiation context of the KMAT is the production location. As both variants are assembled at the same location, they can be combined. The # production order generated from the #MRP run (actually only #P planned order) has a reference to the production location. The # variant that is created is then part of the FAUF (can be seen by the small black box on the FAUF).
If it is now desired to place the products on # stock, we need one # material variant each (4712 and 4713 on the right in the picture). Material variants must be sorted by type. One of the reasons for this is that everything that is grouped in one bin must be subject to the 100% interchangeability principle (form-fit-function principle).
In summary, this means that a KMAT in the production location reference, whereas a material variant is instantiated in the storage location reference.
There are many other instantiation contexts. Which ones can you think of and how are they represented in the systems?
Superclasses of structure types in PLM and ERP
#PLM and #ERP Systems today contain quite different types of structures. In the current industrial discussion about #Digitization companies are becoming increasingly aware that it is necessary to specifically explicate and design these types of structures.
This is also a central key to true #process automationThis is because automated (business) processes run into the void if they jump to another level in their granularity and this is not neatly explicated in a structure.
Does it all sound abstract? - It is.
Nobody understands!
Yes, of course, because hardly anyone is dealing with this problem yet.
However, this knowledge is one of the central keys to business process digitization.
In my video from the series Basics for #Digitalization I explain which classes of structure types exist in the company and how they work.
If you want to know how the connections to real (business) process automation beyond somewhat thin buzz words like Robotic Process Automation #RPA are, then please contact us under info@stzrim.com.
Have fun and greetings
Here the video
By loading the video, you accept YouTube's privacy policy.
Learn more
🔍 Structural theory - Are PDM and CAD-related structural concepts suitable for EBOM and MBOM?
Today I would like to address a question that seems a bit heretical to me. Nevertheless, it has been occupying me intensively for some time.
In a series of posts on the topic of structural theory, I will share my "Best So Far Stand" on the question. 📌 You can find all my posts on the topic of structural theory here: https://stz-rim.com/strukturtheorie/
The question is: "Are PDM and CAD-related structural concepts suitable for EBOM and MBOM?"
Most PLM systems, especially those from the large providers that also have CAD systems in their portfolio, originate from CAD data management and PDM. Their structure concepts are primarily designed for CAD data management. These structure concepts are also used today to map E-BOMs and MBOs in these PLM systems. But until now, there has been little discussion as to whether they are really suitable for this purpose.
I originally thought that this would work without any problems. But the deeper I dive into the topics of ERP and ERP-related PLM, the more I start to reflect.
To do justice to the topic, it is necessary to take a more intensive look at the structural concepts in PDM. A first short insight into this in this post: You can see the CAx-like structure in the picture (detail A). Essentially, such structures differ from BOMs in two main ways: They are subject to revisions (a BOM is controlled by effectivities) and they stamp out the layer instances of the parts (picture - detail B). This is not necessary with a BOM. Here, parts that are used several times can be combined in one application (Fig. - Detail C).
The aforementioned differences require some complex structural concepts that would actually not be necessary for mapping EBOM and MBOM. But are they disruptive? And if so, to what extent? I'll explore that in the next post, where I dive deeper into PDM data models.
🤔 Now to you: How do you see the situation? Have you had any discussions about this? If so, what was your experience?
I look forward to your comments and thoughts! 💬👇
PLM & ERP are growing together - it's high time to get a few old hands together to discuss new classifications, categories and principles.
Where better to do this than in Karlsruhe, one of the birthplaces and headquarters of PLM since time immemorial.
The necessity of readjusting the previous structural concepts and data models, which were still characterized by PDM, is crystallizing. What will these look like, what should they look like?
Tuesday we sat together with xxx to structure the topics as our different perspectives for us. The discussion was very multi-layered and great.
Enclosed are some takeaways from my perspective. Also shown graphically in the image below.
3 layers (not in the IT-technical sense) of PLM are crystallizing more and more clearly. These are:
- 1-Application near Team Data Managment (TDM) Layer
whose task is to manage the proprietary data models of the development-related applications. This includes e.g. classic CAD, ECAD, CAE, ALM tools etc.. They are optimized to manage the data models of the applications. - 2-multistructure PLM layer
PLM means controlling the maturity development of the product-relevant data to the M(RP) capable BOM with which the product can be produced. This requires a number of structures, e.g. requirements structure, system/function structure, installation space structure, EBOM (you name it). The task of this layer is to manage the supply paths of information via these structures and to ensure that the correct information is always available for the subsequent processes. - 3-ERP near PLM layer
Hinentwicklung of PLM information to the local usability heart of the MRP run. Stabilization of F3 (Form Fit Function), execution of supply chain related industrial engineering, management of local content and local customization, addition of MRP levels for controlling, local production planning and control, operational make or buy, provisioning, etc.
What is exciting is my/our assessment of the vendors.
There are the classic vendors that have CAx systems in their portfolio. They come from 1 still focus on 1 and try to transfer the structure concepts and data models developed there to 2.
New or flexible vendors. They have no CAx in their belly and position themselves in level 2. By clever low code close approaches their data models can be extended in 1. The positioning of these in 3 will be seen
Last but not least, the major ERP providers - first and foremost SAP. 3 has always been carried out close to ERP. They have solutions coming from 3 that also cover Layer 2 and even reach up into Layer 1.
It will be exciting how it will develop. I think those who can penetrate Layer 3 first, explain it and connect it with 1 and 2 are in the pool position.
What do you think?
Structure Theory 📘 - Two of the most important insights in PLM that we have overlooked.
Today, as part of my series of posts on structural theory (you can find all posts on this here: https://stz-rim.com/strukturtheorie/) deal with two of the most important insights in PLM. This is, of course, from my perspective - I look forward to comments! 💬
The findings are: 1️⃣ There are 3 PLM layers below the ones we have discussed so far. 2️⃣ There are two types of structures that we commonly refer to as MBOM. This is the M(CAD)-BOM and the M(RP)BOM.
Both findings are related. Now for the explanation 🧐:
Knowledge 1️⃣There are 3 PLM layers (see also the post: Post to the layers)
🔸 Layer 1 - Application near Team Data Management (TDM) Layer: Management of the proprietary data models of applications such as classic CAD, ECAD, CAE, ALM tools, etc. This layer is well known and also established in the VDA model.
🔸 Layer 2 - Multistructure PLM layer (or what we understand as classic PLM): This has the task of managing the maturity development of the product-relevant data. The result of layer 2 is the group BOM (usually EBOM) or else a generic M(RP)BOM.
🔸 Layer 3 - ERP near PLM layer: This is about the development of the M(RP) BOM generated in layer 2.
Related to the layers is also the realization 2️⃣. Both structures, which we call MBOM, are different in their structural levels and elements at the sheet level.
So why didn't we realize this earlier?
Quite simple: The M(RP)BOM is created in layer 3. Its creation is often hidden in the ERP and is not noticed. It no longer plays a role for development. We have discussed industrial engineering away via lean management; so there are usually no longer separate departments for it, and everything happens on demand.
And why are these insights so critical?
For the M(CAD) BOM, we need CAD-centric structures. They can be efficiently realized with classical PDM mechanisms. But the M(RP)-BOM and also the EBOM follow completely different structural principles.
How do you see it? More about this in the next articles on the topic.
Structure Theory - Are PDM and CAD close structure concepts suitable for EBOM and MBOM?
We'll get to the bottom of it. You are at the right place if you always wanted to know how PLM data models work in depth and why quite complex mechanisms arise here. (All my posts on this topic here: https://stz-rim.com/strukturtheorie/)
Let's look at PDM data models. For explanation I use a generalized model which is based on the Teamcenter data model 😊.
PDM data models have two core principles:
- Principle 1: Revisions and loading rules (lifecycle management)
- Principle 2: Occurrence paths with position information (transformation matrix). This creates a relative instance to the layer.
- To Principle 1, revisionsIn detail A on the picture is Item 4712 and its revisions A, B and C. A and B already have a release status (still bored PLM experts 😉). To display the structure, a revision rule is needed (image, detail B). This determines which revision of the structure is loaded (e.g. Working, Status, Precise, Imprecise, etc.). The big advantage of the revision rule approach is that when a new revision is created at a lower level, the entire structure does not have to be revised upwards.
- To Principle 2, Occurrence Paths or Relative InstancesEach CAD model has a position in space, which is mapped by a transformation matrix. In the native CAD data, this is located in the respective parent assembly. In the PDM data model (depending on the PLM system), this is read out and written to the so-called Occurrence (Figure, Detail C). This results in an Occurrence Path (Fig., Detail D). This makes it possible to display the same 3D model in different positions in CAD (item 4712 could hang several times under 4711 with different transformation matrices, Figure Detail E).
Now it actually gets interesting.
An Occurrence instantiates an item relative to its next higher parent item (so 4712 is relative instance to 4711). Why relative? If 4711 were hanging below an item other than 0815 (e.g. 0816 - not shown) and we made changes in the location of 4712 to 4711, then it would change in both the 0815 and 0816 contexts.
In order to create an instance for the context (item 0815), an apperanth path (also absolute occurrence) is necessary. It then instantiates the item to the context. You can imagine this as a thread that collects the Occurrences.
Well, the model is complicated! This results from the desire that revisions can be loaded flexibly, the layer instances are read out as Occurrence Path and instances to the context are necessary.
In my opinion, such models are best practice for PDM!
Are they also for EBOMs and/or Technical Order Structure (TOS)? Especially considering that EBOM and TOS need revisionless elements (material contained) and no transformation matrices in the structure.
Well, what do you think?
If there are Teamcenter specialists among you, please also specify the model.
🔗 Structure Theory - Why EBOM's are Revision-Free! 🚫🔄
In the last post on structural theory, I argued that the data models of most CAD vendors' PDM systems are a bit too powerful and somewhat overloaded for EBOMs and MBOMs due to their adaptation for CAD.
This is due to the fact that CAD-BOM structures need revision mechanisms and also need to display the CAD files in the correct position (see post Post 8)
🏗️💻 You can imagine it like this: It's like taking a truck on a business trip. Goes in principle, but the proportionality seems inappropriate. 🚛➡️🏢
In this post, I start by deriving why EBOMs are revision-free. This is then the prerequisite for formulating the requirements for data models of future PLM systems. 🔄🚫 As always, this represents my current "best so far" point of view. I'm happy to be convinced otherwise. 🧠💬
The key to everything is Form Fit Function! 🗝️💡 Or, understanding which business object runs through the Form Fit Function corridor. This is, of course, the design or drawing of the CAD BOM. It then has a 1:1 relationship to a virtual material that is in the EBOM. From this, one or more real global materials are then born. 🌐🔄
It is often demanded that the material should have a revision. Well, it is subject to a change service that records temporal changes of attributes, but it is not subject to a revision mechanism. The fact that this is possible presupposes that the designs move strictly within the F3 corridor and that development ensures this. ⏰🔄
However, this is where the problem begins. Developers have little time and are sometimes a bit lazy. They therefore tend to combine similar parts in one design. The CAD systems and their automation mechanisms also support this! 🔄🛠️
If this happens, then the design no longer follows the F3 and leaves the F3 corridor. This also gives rise to the often-heard calls to have revisions on the material in EBOM. 🚫🛑
The simple solution: stick to F3 in design, and EBOM is revision-free! ✔️🚫
Why now the virtual material in EBOM sometimes gives birth to several material numbers, in the next post. 🤔❓
I am curious what you think about it and look forward to your comments or even your questions. 📢❓
🔍 Structure Theory - Revealing the Secrets 🚀 - Why Classic M-BOM and M(RP)-BOM are Different Things 💡
In today's post on structure theory, I would like to delve deeper into the secrets of the classic MBOM 📈 and the M(RP)-BOM.
Now to the first questions you're probably asking yourselves. There is only the MBOM, isn't there? It is merely a structure in assembly orientation. Well, unfortunately, neither is true.
What we call MBOM today and what is often confused with M(RP)-BOM is an approach from the digital factory 🌐 that was developed at Tecnomatix and Delmia at around the same time. This was then implemented by PLM manufacturers in their PLM systems. The original aim of this approach was to plan the assembly sequence and make it possible to visualize the assembly steps with 3D data.
The classic way of thinking (see image above: E-BOM to M-BOM) was to reorganize the entities of the substructure of the MBOM so that they correspond to the assembly sequence. Accordingly, the upper structure replicates the individual assembly stations.
As the PLM and ERP systems have moved closer together, a confusion has arisen that I used to fall victim to. We thought the MBOM was the M(RP)-BOM.
What is the M(RP) BOM? It is the BOM via which the Manufacturing Resources Planning (MRP II) run is carried out. It differs from the MBOM in fundamental points!
The superstructure of the M(RP)-BOM contains MRP levels. This means that these are the levels through which we supply production with production orders. They are often also used to cover intercompany processes or controlling processes.
Nevertheless, the upper structure of the M(RP)-BOM and the MBOM could be harmonized with a few compromises. The real difference lies in the substructure!
In the substructure, raw material is added to the M(RP)-BOM, which then also has different characteristics in different works. However, the actual topic is the M(RP)-BOM snippets (film). These are used to regularly exchange material numbers completely, among other things to stabilize form fit function, map local content, precisely control supplier selection, form provision groups, support operational make or buy and, last but not least, add disposition levels for finishing.
Well, that's the way it is. When I discuss this today, the differences are often explained away by PLM consultants, but also by ERP consultants. They then argue that they have often implemented this with classic MBOM and that it works.
The reason for this is quite simple. Today, the supplementary work in the M(RP)-BOM is done downstream by the fairies and heroes in industrial engineering, in the plants or directly in production. They are not visible, they have no lobby, often it is not even known that they exist.
As PLM and ERP move closer together, they will become increasingly visible. And I predict that if we want to implement resilience and sustainability first, we will then urgently need to be able to manage the M(RP)-BOM in ERP-related PLM.
If you want to know how to implement this and why it is so important, please ask us at 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 🔍
I am often asked whether CAD-BOM and E-BOM are the same thing. This question comes up particularly often in the Teamcenter environment and is discussed there with passion, often almost religious fervor.
Here are a few insights:
First of all, from the perspective of pure theory: from a logistical point of view, the materials for the products, i.e. the logistical entities that are moved within the company, must be defined in the product creation process. There are materials that are defined internally (internal design) and others that are defined externally (external design). For internally defined materials, a document is created that consists of a 3D model and a drawing derived from it. This results in two structures: the CAD BOM and the E-BOM (detail A in the post image).
Now to the practice. Since this is a frequent topic in the Teamcenter environment, let's take Teamcenter as an example.
There is the item (detail B in the image), which has revisions. Datasets are attached to these revisions and documents are attached to them (detail C in the image).
The interpretation begins: the item could represent a material and the dataset the document. Both objects and their lifecycle are firmly linked to each other. Since only items in Teamcenter can be converted into a usable structure (BomViewRevisions/PSOccurrence), there is only one structure. From the Teamcenter perspective, CAD-BOM and E-BOM would therefore be the same thing.
This view has been propagated and often implemented over the years. Even today, many consultants defend this approach. They claim that it works.
But why were CAD/Part Alignment and Designs and Parts introduced as separate object types in Teamcenter?
In my view, there are three reasons:
- The item model requires a strict 1:1 between document and material. However, developers (Detail A) often combine parts in documents that do not fulfill the form-fit function, which breaks the required 1:1.
- The E-BOM also contains mechatronic parts. If these were in the CAD BOM, the CAD interface would attempt to read the documents for these parts, which would cause technical problems.
- In addition, maintenance of the E-BOM and CAD-BOM is often carried out by different people. To regulate access accordingly, two separate structures are helpful.
It can work to combine E-BOM and CAD-BOM, but the implicit constraints of this approach can cause serious consequential errors that occur downstream.
What do you think? What is your experience with others PLM systems?
I look forward to your comments. 📝
Find out more in our training course: Methodical Essentials for PLM Experts
2 Responses
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.