In my earlier article How to bridge PLM and ERP Systems To Support Modern Product Development and Digital Thread I shared my thoughts about how two most important business systems (ERP and PLM ) can be integrated to support business processes. The three options I suggested were (1) simple synchronization; (2) implement EBOM to MBOM process in PLM system; and (3) bridge product models and develop integrated applications. There are different ways to build “bridges”. Let’s talk about them today.
Enterprise software history knows many ways to combine software together. It can be done by M&A when one vendor is buying another (a good example of this is Oracle acquiring Agile PLM), creating strategic partnerships (an example is a partnership between Siemens PLM and SAP), but can be also another way enabled by modern technological capabilities and companies goal for digital transformation. Let’s speak about some of these options, pros and cons as well as complexities of existing technologies.
Can we put PLM+ERP in a single box?
I am following the EPD approach with interest and am also associated with this project via a doctorate. In fact, we are getting closer to our basic idea of “one system”. I am already recommending the system to my customers for medium-term PLM decisions. According to Figure 1 and 2, the system is clearly one of the innovators together with OpenBOM by Oleg Shilovitsky. Unfortunately, here comes the typical engineer “but” …. Functional coverage is not yet guaranteed and I still see the old 30-40 year old data model with unrevised parts and a connection of the so-called Effectivity (valid from-valid until) that is completely unsuitable for traceability and Digital Twin solutions. I don’t like to use specific system names in posts, but here’s the exception. Let’s dream of the One-System solution. Let’s mix the Low Code engine of Aras with the functional scope of Contact, the technology of OpenBOM and the strategic and integrative importance of SAP EPD.
According to Prof. Eigner, the incompatibility of data models between Digital Twin and Effectivity-based ERP software and functional coverage can put the delivery of such a system at risks. At the same time, both SAP and Oracle are strategically focusing on the development of PLM software.
Integration Complexities of Existing PLM and ERP Systems
The best example of strategic partnership and integration between PLM and ERP is Siemens PLM and SAP work. I’ve been following this partnership and development of integrated product offering for a few years now. Check my recent article about it – SAP-Siemens Teamcenter Partnership: Competitive Threat or Business Opportunity.
I think the idea is great and SAP/Siemens marketing is brilliant. It helps to think about the opportunity behind development of integrated processes. The discussion about this integrated environment and functional requirements highlighted how complex is to integrate two mature enterprise PLM and ERP.
The integration is clearly solving problems of common SAP and TC customers. As much as I love to see how SAP and Siemens work together, I don’t see such a partnership can develop a broad strategic offering. The main reason for that is high level of diversification in enterprise accounts, multiple use cases, requirements and complexity. Each vendor is big and operating as a single solution will be hard. Which means that very quickly we might see customer demands for SAP integration with Windchill and DS with similar capabilities, as well as Teamcenter integrations with other ERP software.
However, this partnership is one of the biggest contributions to develop integrated solution between PLM and ERP for the last decade which helps to understand use case, functional requirements and technical limitations.
Product Model and Near PLM and Near ERP Layers
Prof. Jorg Fischer brings the ideas of structured data management and development models that can bridge PLM and ERP. Check the following articles about structural theory and how new data model layers can help to connect processes between two systems.
Here is a passage from the article: 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 I like in the model proposed by Prof. Fischer is a clear focus on how to develop and support different data models that can support customer requirements in each functional field – CAD, PLM and ERP.
Implementations and Technological Limitations
One of the biggest challenges of integrated processes and data management are constraints provided by both systems. The need to conform both flexible engineering data management and specific commercial ERP requirements coming from manufacturing resource planning and supply chain management creates an impossible demand and mutually exclusive use cases. Here are a few interesting passages I captured from the comments to the article confirming my thoughts about it:
Martin Ohly: I think there are definitely arguments for and arguments against putting your PLM & ERP functions in one box. I have worked both at companies where this has been done and companies with separate systems. Careful consideration is required to decide on best solution. If your company has a single instance (like SAP) for both engineering and ERP functions, then most likely the engineering will lose out on flexibility and have to surrender to the rigid requirements (like change freezes etc) in a financial critical system. Engineering applications may cause performance issues and an ERP system (at least in my experience till about 2012) is unlikely to provide adequate support for DMU type engineering applications (e.g. automotive or aerospace etc). Another issue is with TDM. Unfortunately the PLM/PDM/TDM of the CAD supplier may either be required, or be extremely beneficial.
Stefan Urbanus The need for flexibility in Engineering is always in fight with the more rigid requirements for the commercial processes. For deep Integration of engineering processes the system with it required supporting rules gets too stiff. I have done lot of fights and activities for optimization and performance improvements. But always we had to go through the gateway of the commercial System supporting rules. So i guess, a critical point for the decision using the commercial system is the roll and complexity of engineering processes in a company.
The implementation complexity of PLM and ERP system is very high. We need to bring new technological capabilities to solve the problem. I can see how cloud technologies combined with new data management systems, graph modeling technologies, new type of queries, data science and AI are coming. Knowledge graph is a foundation of such technologies. KG is capable to model the complexity of constraints from both PLM and ERP software. It can absorb and model the needed flexible of product lifecycle management and engineering models and at the same time provide support for core business processes and business management software. Check my article – The importance of knowledge graph for future PLM platforms.
New technologies and digital transformation will enable a new path in the way both PLM and ERP systems can be integrated and connected.
What is my conclusion?
Digital transformation is removing traditional enterprise software system siloes. It doesn’t mean that we are not going to see separate an ERP software system and PLM software tomorrow. Both systems have their own premise to exist and will continue to develop their own speciality and support specific business processes. Although, I can expect some PLM vendors to continue develop their own ERP solutions for specific use cases as well as I can see how ERP vendors will push the enterprise resource planning software boundaries to support engineering and product lifecycle management (PLM software) capabilities.
At the same time, innovative new technologies supporting modern digital transformation capabilities will be brining new products and services capable to use data from both PLM software and Enterprise Resource Planning systems (ERP) that can be used for collaboration and decision support. These new services will not be specifically “PLM” or “ERP”, but more focusing on improving of process efficiency (digital processes are better) and effectiveness of decisions (AI and analytics). The importance of these processes and services will be huge because they will be focusing on data and not system/software boundaries.
Answering Prof. Martin Eigner’s question “Why not PLM and ERP in one system?”, I’d say that because of current speciality of both domains and implementation status of most industrial companies, the scenario is unlikely to happen. At the same time, I do believe that a new generation of connected services capable to use data from all siloed enterprise systems can bring a new enterprise software layer to support modern product development processes. Just my thoughts…
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.