Structural Theory and How Future PLM will Manage EBOM and MBOM

Structural Theory and How Future PLM will Manage EBOM and MBOM

I’ve been following Prof. Dr. Jörg W. Fischer articles about Structural Theory for some time. Multiple articles published on Linked caught my attention where the topic of discussion was mostly about EBOM, MBOM and various aspects of integrations between CAD, PDM, PLM, ERP (including MRP and MES) systems. I found the discussions interesting, since they are hitting the important topic of digital transformation and how future PLM and other engineering and manufacturing systems will be managing data – engineering BOM, manufacturing BOM management and manufacturing process. Accurate engineering bill of materials and corresponding manufacturing bill of materials are extremely important, especially when it comes to the question of how to orchestrate all the materials and manage engineering and manufacturing BOMs together. This topic is also near and dear my heart and related to modern product knowledge graph data model I’m developing at OpenBOM (disclaimer- I’m co-founder and CEO).

In my blog today, I want to share some of my analysis of Prof. Dr. Jörg W. Fischer Structural Theory and also provide some of thoughts about where I can see PLM data modeling can go related to management of multiple Bill of Materials such as EBOM, MBOM and related business processes.

Structural Theory from Prof. Dr. Jörg W. Fischer

Although many of publications and videos are in German, I finally found some time to go through the some of them that Prof. Dr. Jorg W. Fischer published in English and also used some translation tools to get more information from the publications in German. Here are a few links you can check.

Structural Theory (in English, although the translation is probably automatically done on the website)

Interaction processes and Structures (video 1, also in English)

I found Prof. Dr. Jörg W. Fischer theory hitting the nail when explaining the importance of data management in different processes. The following picture taken from the video (link above) give you an idea of two parallel worlds – process and data.

As a foundation, you can see an example of different structures – Design BOM, EBOM, Configured Product Structure (eg. colors), MBOM.

I think, Prof. Dr. Jörg W. Fischer is correct when describing the pain of multiple structures and the need to provide robust data management to support various processes such as MRP run, supply chain management, and others.

The picture above explains the complexity of data structures that need to be done to support engineering and manufacturing processes. These structures are complex and to manage them can be messy when you need to define them using traditional CAD, PDM, PLM and ERP systems.

For me, the most important aspect of the Structural Theory is the idea of contextual link between items that allow to manage different structure types – EBOM, MBOM, etc. Which brings also a question about multi-view BOM strategy. But let’s talk about this in the next chapter.

From EBOM to MBOM and Multi-View BOMs

Managing multiple Bill of Materials is a topic that comes in the so called “Layer 2” in the definition of Structural Theory. You can see it in the picture below explained as (1) “near TDM” EBOM and (2) “near MRP” MBOM.

The explanation is emphasizing the importance of PLM to support CAD design structures (usually done by PLM vendors having good integration with CAD systems) and then rich ability to manage MBOM specific product definitions.

In existing PLM tools, the best support of this process is done using so called EBOM to MBOM process, which is usually requires an agreement about how to manage multiple BOMs. One of the main questions is here about BOM management: single BOM, multi-BOM, or multi-view BOM.

While most of companies are still focusing on dual BOM (EBOM to MBOM) approach, I can see questions raised by Prof. Dr. Jörg W. Fischer are touching methodology how to implement multi-view BOM using multiple structures.

In my article about multi-view BOM management you can see options how to implement it using (1) one system; (2) multi-system federation and (3) service augmentation. This is what can be done today.

Product Knowledge Graph and Multiple BOMs

In my view, the most exciting part of future multiple BOM support (including modern product structures) can be done using product knowledge graph technologies. In my article about BOM evolution into digital BOM, I shared ideas about how multiple modern technologies can be used to create a robust data management platform to manage product structure in a way of product knowledge graph to support multiple digital processes.

What is Knowledge Graph?

A knowledge graph is a data structure that represents information as a network of interconnected entities, where each entity is represented as a node and each relationship between entities is represented as a link or edge. Knowledge graphs are designed to capture and organize complex relationships and dependencies between different pieces of information, enabling more efficient and effective data analysis, search, and discovery.

Knowledge graphs can be used to represent various types of information, such as facts, concepts, events, and entities from various domains such as medicine, finance, or entertainment. They can be built using various techniques, including natural language processing, machine learning, and semantic web technologies.

For the last decade, knowledge graphs have had a wide range of applications, such as in search engines, recommendation systems, and chatbots. For example, Google’s Knowledge Graph is used to enhance search results by providing information about entities and their relationships, such as the relationship between a famous person and their works, their date of birth, and their profession.

I wrote about Knowledge Graphs in the past. Check my earlier articles. I expect Knowledge Graph technologies to provide valuable technology to build a future of digital BOM and data modeling for PLM and other enterprise applications for engineers and manufacturing.

Digital Transformation and End-to-end processes

The key aspect of digital transformation is (1) moving from documents to data; (2) organization of information flow and (3) connecting data and activities between multiple departments, systems and companies. To make such thing happen, we need to have much more robust data infrastructure with data modeling tools capable to manage rich product structure models. I can see usage of graph databases, combined with scaleable and flexible data modeling platform as a foundation of this process. Multiple product structures (multiple BOMs) support should be part of this digital transformation process.

What is my conclusion?

How to organize a data to deliver a complete and shippable product? This data must include, various aspects – design, multiple BOMs, manufacturing data, supply chain and many other domains. This is a question modern manufacturing organization need to answer to support digital transformation of the businesses. You cannot get this information in a single process. Therefore, connected information sets is the only answer.

Organization of connected information flow to support connected digital processes is a main goal in digital transformation. To achieve that, modern PLM systems must provide robust data modeling platforms for robust product structure management. I think, this is a place where I see the research and work done by Prof. Dr. Jörg W. Fischer very important. The main question I have is about how industry will move from last 20 years of EBOM to MBOM sync to understanding of complex structures that systems need to establish to manage data and connected processes. This is a question to all PLM architects, vendors and PLM and ERP consulting companies. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital-thread platform with cloud-native PDM & PLM capabilities to manage product data lifecycle and connect manufacturers, construction companies, and their supply chain networks. My opinion can be unintentionally biased.

Share

Share This Post