PLM Downstream. Why nobody likes PLM outside of engineering and how to fix it in 2020

The original article was published on my Beyond PLM blog.

The year is going to the end and this is the usual time to publish "what is important in the next year" blogs. I will not disappoint you this year and will share my thoughts about 2020 and beyond.

Here are two articles (in case you missed). Next decade of PLM: SaaS, Digital Thread, Model-Based System Engineering and maybe more… and PLM technology differentiation in 2020. Let me talk about one more topic, which I believe will be on the top of PLM minds in 2020. And this is downstream PLM usage.

In the last decade of PLM, we've seen significant improvement in understanding the role of PLM in the organization, ROI, use cases and implementation strategies. However, "the love" for PLM is significantly dropped when you leave the doors of engineering and product development. In the outside of the engineering world, PLM is perceived as an expensive engineering tool that cannot be realistically used in other departments. This is probably not big news for anybody. In the past, I've seen two most commonly used scenarios of downstream application usage: (1) ERP and (2) manufacturing planning. The first is mostly about BOM transfers, change management, and formal ECO process. The second was about downstream CAD data usage outside of engineering.

PLM and PDM systems must feed data downstream to ERP database to combine engineering and business data, restructure it and allow extended enterprise to use the data. The typical functions outside of the engineering consuming the data are supply chain, customer, financial, procurement, variety of metrics and KPIs. The core data elements that send downstream is Bill of Materials and sometimes visuals.

The main challenge of the downstream process is to share data from the PLM system. Because most of the engineering systems are not available downstream, the engineering data is extracted, converted, transmitted to these downstream users.

Here is a typical way to think about the data is flowing downstream - multiple Bill of Materials. I captured Archer Grey slide about synchronized BOM here. You can see a variation in the way data is presented, but this is how it looks like.

In a more sophisticated marketing presentation, the connected and synchronized BOM structures are defined as "digital thread".

You can see multiple structures of Bill of Materials - Functional, Engineering, Manufacturing, Service, Build, etc. The process of BOM synchronization is painful and also combined with significant data transfers (syncs). Keeping the Bill of Materials synchronized is a big deal and a lot of work. In many organizations, this is a big "Excel kingdom". The most advanced PLM implementations are using EBOM to MBOM process, which I will also address separately.

The second major downstream usage is related to delivering CAD data downstream. And this is where you find most of the manufacturing production planning functions that impossible to imagine without CAD data derivatives. CIMdata published really interesting research a few years ago speaking about CAD downstream usage. Check it out here.

The intent of this project was to explore the relationships between advanced CAD capabilities and integrations that enable downstream use of the CAD data, and how data standards impact these integrations. The ultimate goal is to provide a base of information and insights from which the A&D Action Group can develop direction statements to guide the efforts of solution providers and standards organizations to produce more sustainable solutions

This is a picture that gives you an idea of data exchange issues:

The main challenges of the downstream are in complexity of processes, siloed organization and people who want to control the data. From my experience, it is very hard to present long term ROI for downstream usage. Companies are managing efficiency in very different ways. I remember one company that was counting the number of transformation data is going through from CAD to procurement. The trick is to communicate the true business efficiency. ERP integration topic usually comes in every single PLM implementation I've seen, but many companies are afraid of complexity to keep it down to manual data exchange. But the topic is super painful for every single organization. Increased complexity of the product and the demand to speed communication for mass customization and advanced engineering to order works can easily bring PLM-ERP use case up to one of the top criteria related to the decision of moving ahead with PLM implementation.

But there is some good news. Companies are now focused on Digital Transformation and these projects are focusing on how to transform communicating and other processes by using new digital technologies. In my view, this is also an opportunity to improve downstream data usage. The later can be a big deal for PLM companies. Digital transformation won't make PLM-ERP easier. Actually it can make it more urgent. Modern systems offer many advantages. However, these systems require applications to extracting data and using web services instead of old fashion Excel export files. This is a piece of good and bad news at the same time. Data is more accurate, but integrations are absolutely needed. In the past, you've been able to dump data into Excel "messware" and then blame people for mistakes.

The wide adoption of digital transformation is coming on top of the growing complexity of product data, demand for mass customization and a growing number of engineering to order product development. Customization is everywhere. Therefore I can hear voices towards establishing the so-called "digital thread" of data and related information pieces. The speed of data transfer is significantly impacting the adoption and this is how manufacturing companies will be coming back to improved communication and data sharing downstream as an opportunity to improve the processes and make them "connected".

So, what does it mean for PLM vendors and other companies in the business of engineering and manufacturing software? I can see two main opportunities that can convince PLM vendors to move faster into solving the problem of downstream application usage.

1- Data as a Service

By providing information downstream, CAD and PLM vendors might discover new business models which will be totally relied on data usage. Modern multi-tenant data management systems can deliver a sufficient amount of intelligence that can be used later on to optimize decision support.

2- Streamline Processes and Improve Data Handover

An increased interest in connecting people and processes raises the question of how to improve the sharing of information. To provide real-time access can become a significant business driver. It goes both ways. Knowing what downstream users need can also help to optimize the process of data sharing without sacrificing the speed of communication.

What is my conclusion? Manufacturing is transforming and this process created a real demand for changes in the way systems and data are integrated. As manufacturing companies are moving forward, the danger for PLM vendors is to stay with two-decades-old technologies in isolation. New SaaS software vendors can iterate fast and sell products and services to customers, performing upgrades after upgrades to improve data flows and simultaneous data access. In order not to say locked, CAD and PLM vendors should innovate in the downstream applications to make data easily available, shared and integrated. Cloud services and SaaS applications can provide services for downstream users and lock the CAD/PLM system in the old scope of engineering, which won't be a good thing for CAD/PLM business. Therefore 2020 is a great year to focus on data availability and data intelligence to insure future PLM business. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing cloud-based bill of materials and inventory management tool for manufacturing companies, hardware startups, and supply chain. My opinion can be unintentionally biased.