LinkedIn post 1
ERP-related PLM - What is it actually?
Today I would like to explain Paradigm 1, the Object Type Cascade.
The cascade of object types describes the chain of objects that will be needed in the future to stabilize lifecycle management through to ERP and beyond.
The need for the ERP-related PLM layer is demonstrated by the stabilization requirement on the store floor. The principle applies that every employee in the entire plant network on the store floor must be free to decide which part to take from a storage bin. They must all fit under every condition!
This requirement is an absolute must for CTO and especially CTO+ process samples. With ETO and STO, it could still be treated lazily.
So when you start to implement this principle, you realize that it is no longer possible to hide completely different aspects under one material number, but that you have to accept that under certain conditions, one part in PLM can give rise to a variety of materials in ERP. You could also say that several materials are created in ERP from the part in PLM.
This happens regularly today! We often find it in our structural analyses. However, the problem is that this happens downstream in the supply chain and is therefore invisible to development. This is why this effect is often negated or denied by PLM consultants or development departments. However, people in the supply chain regularly confirm these effects.
In order to be able to model this aspect reliably, you need an object close to the ERP as a bracket, via sufficiently similar materials, so that the part object in the PLM can be linked traceably with the materials created from it in the ERP.
Consistently thought through, this results in a chain of object types (see post image), which emerge from each other in a cascade.
This results in paradigm 1, that of the object type cascade.
It postulates the need for a chain of networked object types that can ensure stable, audit-proof traceability of the objects created in the course of the PLM processes from PLM to ERP at all times.
Today, there is still a gap in this chain, as it is generally assumed that a part in PLM corresponds to a material in ERP.
In the picture you can see what the chain should look like from the RIM perspective. As always, it is our best so far knowledge. I will be happy to provide a more detailed description in a follow-up post.
If you realize in your company that your parts do not actually correspond to the material, it is better to address this immediately. The risk that arises if you have not realized the Object Type Cascade should not be underestimated.
We are happy to support you from STZ-RIM to develop and implement an appropriate, sustainable concept.
LinkedIn post 2
ERP close to PLM - dimensions of a material bubble 🌐
Let's delve deeper into the incredible 🌍 and exciting world of ERP-related PLM 💡.
In the last post, I described the first paradigm of ERP-related PLM. I stated that in many cases, a part in PLM can be supplied to ERP via material realization in the future, creating a material bubble.
Today I would like to look at the dimensions of the Material Bubble and explain why and how material is created in the Material Bubble.
First of all: Yes, it is possible in principle to implement PLM and ERP without taking the material bubble into account and pretend that it does not exist. This then leads to a number of very unattractive effects downstream. These may even remain invisible for a long time after implementation. The symptoms only show up later and in completely different places!
Now to the dimensions:
Dimension 1: Location (Plant): The material must be created in the plant reference, as material is planned differently in different plants and often has different raw materials.
Dimension 2: F3 (Form Fit Function Stabilization): If a component is managed via revisions in the F3 corridor during development, it may interpret the corridor too broadly. Likewise, interchangeability from a development perspective is often different than from a production and full traceability perspective. As a result, a new material number may have to be created for a revision or summarized for several revisions to safeguard F3.
Dimension 3: M(RP)-BOM snippets: For a number of reasons, material numbers must be exchanged in the deep structures of the M(RP)-BOM. This applies to finishing parts, for example. There are a number of other cases that are exciting here, e.g. the Early and Late Component Decision and operational Make or Buy... In many customer discussions, these cases now come up and we at RIM have systematized and described them.
The task of Material Realization is then to form a bracket around the material bubble in the ERP-related PLM.
Now that sufficiently describes Paradigm 1 and the Material Bubble for LinkedIn. You can get further details and support with implementation from us at STZ-RIM.
I look forward to your comments and if you can think of any other cases for M(RP)-BOM snippets, I would also be very curious.
#ERP #PLM #MaterialBubble #SupplyChain #Innovation #Technology
LinkedIn post 3
Paradigms for ERP near PLM - Paradigm 2 - Generic Structure Instance Embedding 🌐💼
Today I would like to introduce Paradigm 2, Generic Structure Instance Embedding. 🔄📈
The digital supply chain is changing fundamentally. On the one hand, it is necessary to gain the ability to deliver products with many variants at prices and delivery times of standard products. On the other hand, they are under pressure from market and political influences, and there is an urgent need to make them highly flexible and much more controllable.
Today, two main approaches to implementing the modular kit for the CTO+ are being discussed in the industry:
Coming from the ETO, the development of a non-industrialized engineering kit that has to be laboriously industrialized when an order is placed.
Coming from the closed CTO, the generic product structure approach, which is already industrialized but does not sufficiently cover the + share of the CTO (+).
This results in Paradigm 2 - Generic Structure Instance Embedding. It consistently develops the classic approach of the generic product structure.
The approach of a generic product structure assumes that the superstructure of a product is generic, i.e. structuring. From a dedicated structure level, the product structure is then completed by components/assembly instances via items/item variants.
The future approach, which we call Generic Structure Instance Embedding, consistently develops the classic approach further. It will make it possible to implement a growing CTO+ modular kit. This modular kit is then a hybrid modular kit. This means that the modular kit is already fully industrialized to the maximum possible extent.
So what is the methodical approach of Generic Structure Instance Embedding? The generic structure is continued into the deeper levels of the product structure. The boundary between structuring and instantiation disappears. The instantiation is no longer horizontal, but vertical to the structure, and a "double structure" is created that contains both the instances and the generic structure. This enables automated instantiation, which can also include the CTO+ part, right down to the lower structure levels!
As I'm running out of space for this post, I'm afraid I'll have to leave it at this short text. I look forward to your questions and comments. I would then use them to generate follow-up posts.
Please understand the formulation of the topics here as an invitation to PLM and ERP vendors. We would be happy to discuss with you why this approach is necessary and whether and how it can perhaps already be implemented in your PLM or ERP systems today.
