The credit for the picture above goes to Martin Eigner book about System Lifecycle Management.
I’d like to continue the discussion I started in my previous article – Structure and models of product data for connected processes in PLM. The main point of my previous article was that manufacturing industry and PLM software vendors specifically need to find an architecture and technology that can be used to manage product information to support effectiveness of decision making process and efficiency of engineering and manufacturing processes.
The complexity of business processes in a modern engineering and manufacturing world is growing enormously. PLM systems are struggling with complexity of document management, product data management, change management, supply chain management. A PLM system that was developed in 1990s and gradually improved over the last 20 years looks like extremely efficient ICE that can do exactly what is supposed to do, but cannot become electric.
Modern data management technologies, web and cloud architecture can bring a new foundation for modern PLM software. Which will allow to new generation of PLM software to bring new capabilities to computer aided design, process management and enterprise resource planning. However, to make it happen companies need to figure out the technological and business roadmap. The changes won’t happen overnight, companies made substantial investment in existing technologies and products. Therefore it will take time and strategy work to bring new technologies and tools to companies and to help them to achieve the desired improvements. However, it is more and more clear that for manufacturing businesses it is a matter of survival in a modern business environments.
3 Levels of Complexity in Product Data Management
Let me start from the complexity of product data and the requires for data management and process modeling. The product data management depth and sophistication can vary. I highly recommend you to check my earlier article A look intro system lifecycle management book by Martin Eigner from 2021. It describes the complexity of product development environment as we see it now.
I’d like to define the following 3 levels – (1) Basic: Documentation level; (2) Structured: Product Data Management; (3) Integration: Process and analytics. I’d like to speak about each these levels to explain what is behind and why the level of complexity is unprecedented in the modern manufacturing business.
Basic: Documentation Level:
At this level, product data primarily consists of basic documentation and records. The information is usually includes 3 models, but also specifications, requirements multiple files and sometimes even physical documents.
This is a level where the most powerful paradigm that exists in the world today – Folders/Files is used to represent everything that companies are doing – from 2D/3D design and system diagrams to part lists/ BOMs in Excels that transferred between companies, contractors and suppliers.
The complexity of this level is usually focused on the multi-user access control, revision management, and collaboration. Communication and connectivity is another aspect of data management challenges in this level. Companies are working together and to have reliable access to all information is not a dream, but the need of every manufacturing company, supplier and contractor.
Structured: Product Data Management Level:
This level involves the need to deal with a greater complexity of product data. This is a level when companies are managing data together wit documents that represents different aspects of product structure and dependencies. It starts from basic design structure representing assembly-component relationships, but then growing into multi-disciplinary product data (mechanical, electrical, electronics, software) combined with even more complex requirements and system design information. Moving downstream structure data management becoming even more complex with the need to represent manufacturing product structure and planning. Expanding even more, we will come to structures that need to cover all phases of product lifecycle including sales, maintenance and support.
This level today is represented mostly by PLM and ERP systems storing data in dedicated PLM databases and variety of other customized data management systems. Data is centralized, CAD models, and all related documents are integrated together and connected by Bill of Materials (product) structures.
At this level, the complexity lies in the following to dimensions- complexity of product structures (multi-BOM) and transformation and synchronization of data between lifecycle stages (eg. EBOM to MBOM transformations). Data structures are becoming complex and it takes a significant efforts from companies to customize and organize support for this type of information.
Integration: Process and Analytics
It was a dream of having a single vertically integrated system to take care of all aspects of product development, engineering, manufacturing, maintenance and support activities. The dream is over and the reality is complexity of organization of end to end processes, the complexity of modeling product value chain and integration of multiple phases of engineering and business processes that are controlled by multiple systems.
The first aspect of the integration complexity level is related to the complexity of change management in this structured product data management environment. Workflow automation is main approach that used to support change management process, approvals and collaboration. Product data at this stage can be enriched with additional elements of metadata make it easy for users of the systems to search and retrieve for information. But having product data intertwined between product configurations, development and planning stages, organization of supply chain makes this level of complexity to skyrocket. Here are just a few examples of the most painful data management and integration problems – organization of multi-BOM environment, data integration for virtual product simulation (digital twin), connectivity between all elements of data presented in different development stages and systems (digital thread).
At this level of complexity you won’t find any standard solution that can fit the needs of manufacturing and product development environment. Today, it is a bleeding edge of PLM and related technologies where companies are organizing separate databases for advanced analytics and integrations. Data analytics and machine learning tools can be used for predictive maintenance, performance analysis and optimization. Various integration technologies and data hubs are used for integration with Enterprise Resource Planning (ERP), Manufacturing Execution Systems (MES), and Internet of Things (IoT) platforms. All together enables real-time data sharing. Digital twins and simulation data may be utilized for virtual prototyping and testing. Advanced security measures are implemented to protect sensitive engineering data. AI-driven decision support systems may be employed to optimize product design and manufacturing processes.
The Problem With Existing PLM Technologies and Architectures
For the last 20 years product lifecycle management software was developed as a technology and platform to support design and engineering processes. This is the foundation of PLM as know today. At the same time, multiple efforts and development were taken to expand PLM software and technologies to other processes. There are many examples of PLM expansions for the entire lifecycle cycle from requirements and system design to manufacturing planning and sales support. These implementations are not happening out of the box and requires stepping from a simple PLM software implementation roadmap towards development of PLM business and technological strategy.
My opinion is that software technologies of the 90s are no longer relevant for future PLM systems (see my comment to Jörg Fischer). I would like to illustrate this using the example of the Digital Thread and Multi-BOM. My extended View on Digital Thread is the connection of the configuration items, i.e. the information elements to be considered in the event of a change and their affiliation to engineering processes, for example engineering change or quality management. The main objectives are to support the reconfiguration (according to EN DIN 9000/9001) in the event of damage and to support change management to determine the affected items and processes (Fig. 1). The Digital Thread is a highly networked graph.
Let’s talk about current PLM technologies and architectures and explore why current state of technological development of PLM software is lagging behind of what manufacturing industry, product development process and manufacturing process are demanding.
I’d like to identify the following technological limitations of existing PLM software.
- Majority of existing production level CAD systems are desktop systems using file management systems to store information. The document is a foundational element of engineering design, which brings a substantial level of complexity because it is limiting the granularity of data access, data management, intent and impact analysis.
- Majority of existing production level PLM systems are SQL-based client server and sometimes web-based architectures with RDB-based servers. These systems were designed back in 1990s where the methodology of object-data management was used to create an abstraction level for flexible data management using in all existing major PLM software platforms today. The computation capabilities of these systems is limited to capabilities of RDB/SQL and abstraction model is limited to a single tenant (company) level.
- Integration capabilities of existing major PLM software tools is limited to proprietary APIs and limited development of SOAP/Web services interfaces. Customization and integration best practices are relying on direct access to database and (again) using SQL for data extraction and processing. Moreover, business models of vendors is relying on data locking and selling vertically integrated solutions.
It is important to analyze these limitations because these are also big opportunities for modern PLM technology development.
What is my conclusion?
The complexity of engineering product data management can vary widely depending on the industry, organization size, and specific product requirements. Therefore, we can see existing PDM/PLM/ERP systems demonstrating success and support to engineering teams and manufacturing companies in some companies, especially when companies are applying enough efforts, methodology and education.
Existing systems are not dead, but provide significant challenges in both SMB/SME and enterprise segments. For SMB/SME customers, existing PLM solutions are struggling to provide a simple yet efficient organization of data management, integration with existing design systems and change management support. An attempts of host existing PLM suites using cloud platforms (AWS, Azure, GCP and others) are limited functional and expensive to maintain. For enterprise, the use of limited data management capabilities of existing software and absence of modern data modeling, integration, analytic and AI-based tools introduce a huge struggle to present a vision for data management beyond 2030 horizons.
Unless you expect existing RDB/SQL backend to serve manufacturing processes like you can see existing COBOL based systems still serving some financial organization, companies need to find a better way to manage product data and provide solutions to serve three levels of product data complexity I outlined above. Just my thoughts…
PS. In my next article, I will speak about possible strategies to solve the limitations of existing PLM technologies and provide a path forward for organizations to re-use existing investment in PLM solutions in their future strategies.
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.