In the era of digital transformation, the integration of complex systems and data models has become a pressing challenge for businesses across various industries. One of the most challenging integration scenarios is between Product Lifecycle Management (PLM) and Enterprise Resource Planning (ERP software) systems. PLM and ERP operate with fundamentally different data models – fundamentals of PLM relies on a revision-based product structure, while fundamentals of ERP uses an effectivity-based model that excludes revisions. Bridging the gap between these two systems is often painful and complex. Without efficient integrated management, companies often rely on manual processes between business units, enterprise resource planning and PLM software systems. Key business functions of PLM and ERP systems are different and, as a result product data modeling used by both systems.
In the past, PLM and ERP systems operates in a more independent ways, which allowed more simpler mechanisms like ‘data sync’ to send CAD or any related data from engineering environment to enterprise resource planning software (at the beginning it was even MRP, manufacturing resource planning). An increased complexity of product (mechanical, electronics, software), and complexity supply chain management, combined with increased complexity of business processes and business models, created a demand for both engineering and manufacturing environment to be more dependent on each other. Combined with demands for digital transformation brings many questions related to traceability between data located in both systems. ERP solutions along cannot keep up with the business without properly integrated PLM software systems. The holistic integration of different software systems is needed – customer relationship management, accounting software and business management software.
In my article today, I’d like to share examples of complexity integrations between systems such as PLM and ERP and also to speak about benefits of using a graph-based digital thread product model for PLM-ERP integrations, highlighting its advantages in addressing the complexities of this integration.
Integration Complexity, Near PDM and Near ERP layers
For quite some time, I’m following the publication of Prof. Jorg Fischer about structured data management and integrations between PLM and ERP systems. In my view, this research demonstrates the complexity of integrations and incompatibility of data models. Check the article published earlier today on LinkedIn about the need of ERP near PLM layer.
Here is a passage from the article.
The necessity of the ERP near PLM layer is evident from the stabilization requirement on the shop floor. It’s a principle that every employee in the entire factory network on the shop floor must be free to consider which item to take from a specific storage space of a material. They all must fit under every condition! 🏭👷 This requirement is an absolute must in CTO, especially in CTO+ process patterns. In ETO and STO, it could still be treated lazily.
When you set about realizing this principle, you find it’s no longer possible to hide completely different aspects under a single material number; one must accept that under certain conditions, a part in PLM becomes a variety of materials in ERP. You could also say that from the part in PLM, several materials in ERP are born. 🚀🔗
An interesting part of the proposed model is object cascades. Look into this model and you can clearly see multiple objects and their relationships: TDM object, Parts (revisions with the same FFF), PLM Material, Virtual Material and ERP Materials.
I can see how this object cascades can help to connect different concepts and data objects. At ths same time, from my experience, I can see how a possible demand for customization of this data relationships model. It can dependent on a specific customer needs or specific PLM and ERP system.
It made me think about the implementation and integration between system using graph based product model. I discussed it in my earlier article Digital thread and Future PLM Software architecture. The new architecture can be be used to establish a service to support flexible product data modeling and allow seamless integration between PLM and ERP systems.
Graph Based Model Approach
The Graph-Based Model Approach: Among the various approaches available for PLM-ERP integration, the graph-based product model stands out as a promising solution. This approach leverages a micro-service architecture to introduce a model that utilizes a graph database as the primary tool for creating a specific set of objects and relationships. This model acts as a bridge between PLM and ERP systems.
Why graph database and why now? What it can give that existing PLM systems cannot support? Let me answer these questions by comparing old PLM architecture and integration technologies. A typical PLM system is an object modeler built above RDB. For the last 20+ years of PLM development, these object modelers became quite sophisticated. A typical model for different data representation in each PLM system is multiple BOM structures (xBOM). A more advanced PLM models developed mechanisms to built complex relationships between design, engineering BOM and manufacturing BOMs. At the same time, flexibility of data modeling for these systems is limited by RDB capabilities and SQL queries.
If you’re interested to learn more about graph database vs relational databases, I can recommend you the following Udemy course about knowledge graphs. Although, if you’re busy just check the following video:
Graph data model and graph databases provides a more powerful and flexible mechanism. Combined with other databases (polyglot persistence), a digital thread model can be more robust and serve a bridge between multiple systems. Here are three key benefits of graph-based models:
Supports Greater Data Model Complexity:
Graph-based models excel in handling complex data structures. Unlike traditional relational databases, where data is organized in tables, graph databases represent data as nodes and relationships. This flexibility allows for the representation of very complex and detailed product structures, making it easier to map PLM and ERP data.
Easier Evolution of Data Model:
Nothing is standing still and business systems are evolving. One of the challenges of many existing PLM systems was to maintain the required level of complexity as systems are evolving, Businesses require the flexibility to adapt their data models as needed. Graph-based models offer an advantage in this regard. They allow for seamless evolution and modification of the data model without significant disruptions to the integration process data upgrades
Simpler Relationship-Based Queries:
Last, but not least is a query power of graph databases and data models. Graph databases excel in handling relationship-based queries. Here is an example from Neo4j book comparing graph database and SQL system performance. Check it here – How much faster are graph database, really.
For example, in a social network, finding all the friends of a user’s friends. Even more so for friends of friends of friends. Aleksa and Jonas built this query in both MySQL and Neo4j with a database of 1,000,000 users and the results are striking. Execution Time is in seconds, for 1,000 users.
When integrating PLM and ERP, understanding the connections between various data elements is crucial. Graph-based models simplify the process of querying and extracting meaningful insights from interconnected data.
What is my conclusion?
The evolution of PLM-ERP integrations calls for innovative approaches to bridge the gap between different data models and core business processes and both PLM and ERP software system. The introduction of a digital thread graph-based data model offers a promising solution. By leveraging the advantages of graph databases and microservice architecture, this approach enables businesses to create a more robust and efficient integration between PLM and ERP systems. As industries continue to evolve in the digital age, embracing new approaches like graph-based models is essential to stay competitive and streamline processes effectively. Just my thoughts…
Best regards, 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.