There are many interpretations—misinterpretations—of what PLM is about: how to define it, how to implement the tools supporting it, who it is for, who needs to understand it, and most importantly, how to realize value from it. Others argue about how to sell it and how it relates—or doesn’t relate—to the underlying tools and technologies used to implement it. This post explores the six most commonly encountered myths about PLM.
Myth 1: PLM is a Tool (or to narrow it down further: an “engineering” tool)
This is the recurring debate that, at times, can get very emotional. The debate has deep roots which go back to product data management (PDM), as well as basic engineering collaboration tools. Most “PLM platforms” used in the manufacturing sector evolved from the world of 3D and CAD data management and expanded to manage the relational data of the whole enterprise. Simply put, PLM covers the “process to create” products, including the creative design, and now digital twins. It encompasses every activity and function involved directly and indirectly in the product creation process: designers, engineers, product engineers, manufacturing engineers, shop-floor assembly engineers, service engineers, product attribute managers, sales and marketing managers, etc. The “toolset” or system element is the means to the end: to enable data traceability and automation. PLM started as a tool and has evolved into a discipline. It took 20 years. Now it’s here and it will continue to reshape and evolve.
PLM is not only about engineering, it is also about converting ideas and concepts into virtual simulations and digital models, ultimately leading to physical products and associated services. Arguably, a significant part of the product creation process is rooted in engineering. However, we as engineers, are also a very conservative people.
Many functions beyond engineering are intrinsically involved in the product creation process: marketing, sales, manufacturing, supply chain integration, finance, procurement, program management, quality, compliance, etc. They don’t call it “PLM” but they carry several overlapping disciplines.
Myth 2: There is No Value from “PLM”; No Need for a Business Case to Define Expected Benefits
Value from PLM is hard to measure as it is not only about resource or process efficiency. It is also difficult to measure how effective people are at collaborating or creating great products (before they actually create them). The fact that it is complex does not mean that it has no value or should not be looked at properly. On the contrary, it actually needs to be explained over and over in context of improving operations and business change.
Typical business benefits from implementing PLM solutions focus on better data and change traceability, more effective issue identification and early resolution, improved supplier delivery performance, reduced product creation cost, reduced rework and data duplication, improved quality product, robust / on-time virtual build, reduced number of physical prototypes, improved concurrent engineering (aka collaboration), improved right first time product manufacturing and assembly, etc.
The PLM business case typically starts “top-down” to get stakeholder buy-in and converge on the required investments and approvals, based on a combination of:
- New business capability introduction—including visualization, simulation, and cross-functional data integration, vertical and horizontal process alignment.
- Existing capability improvement—building on new and existing processes and data, based on change management and automation opportunities.
As organizations embark on PLM implementations, initially through the realization of demonstrators and proof-of-concept, the business case can be validated (and adjusted) against a more “bottom-up” approach to benefit calculation. This contributes to making real value from the business change, putting in place new operational efficiency measures and scalability targets. Educating business leaders exchange with SMEs about this iterative process is critical to avoid misunderstanding.
Failure to realize value from PLM is often linked to failure to measure operational efficiency, value from automation and capability enablement. This can also be amplified by continuous changes of business strategy, requirements or even executive sponsorship before benefits are officially realized. This reinforces the need for an all-encompassing big picture approach and ongoing “business change” and stakeholder management—continuously (re-)aligning top-down and bottom-up expectations. Creating the illusion that PLM will transform everything is can be equally dangerous as reality misses on surreal expectations.
Myth 3: Any Organization Can Simply "Buy" PLM, and Use it Out-of-the-Box
Most organizations will not look at simply buying a tool or platform to enable PLM related processes. They expect operational efficiency and implementation “best practices” to help them become more effective and competitive: i.e. “do more with the same” resources and be able to scale their activities while reducing cost. Whereas buying apps or tools is quite straightforward via a license model, making good use of an integrated and streamlined working practice across multiple functions is not always obvious. This can be quite complex based on product or process requirements which can be contradictory at different product maturity stages.
In addition, most enterprise digital platforms now cover a lot more than what former “PLM system” used to deliver. Buying a PLM platform is not a simple decision as it typically involves medium to long term commitment to a vendor, and short/medium term engagement with a strategic implementation partner.
Even if they cover more scope, no single platform or tool can stand “out-of-the-box” (OOBT) on its own unless only covering a very narrow self-contained scope; implementation complexity rises with product, data and business model complexity, in addition to multiple legacy ERP and MES integration points and legacy data migration requirements. PLM processes need to be contextualized for any “brownfield” organization wanting to get value from it. Similarly, for start-up or “greenfield” organizations, PLM processes need to be tailored to the business maturity—aka customized in a controlled manner, balancing short- and long-term requirements.
Myth 4: PLM “Best Practices” are Universal
Transferring “best practices” from one organization to another is clearly a myth: only the learning can be shared but there is no guarantee that what worked elsewhere will be as effective somewhere else. Some practices will certainly work in small pockets of scope. However, working practices cannot be fully reproduced out of context, even if the system implementation can be copied. Every organization is unique, has its own legacy of challenges, from a data and process perspective. This concerns both start-ups and “brown field” companies which will be able to implement business change at different pace and levels of success based on their expertise and context.
It is not uncommon to hear about “industry-ready” bundles. These often come at the price of process and integration compromises. They combine with the uncomfortable truth that there is no such thing as one-size-fits-all solution. Whatever capability is in the box, a number of core principles underpin any PLM initiative; it is important to look at strategic alignment, short- and medium-term compatibility when selecting any technology vendor (and their implementation partner) to minimize deviation from the OOTB standards where possible.
Failing to understand these principles implies lengthy PLM implementation and future maintenance nightmares.
Myth 5: PLM Platform Configuration is Good, Whereas Customization is Bad
There are probably 10 or more definitions of system configuration and customization for enterprise digital platforms. So, let’s not go there. To be effective, PLM processes must be tailored to the enterprise what will be using them.
Every digital solution requires some sort of tailoring design, including adaptation and integration with the rest of the enterprise—because they are “contextual” and (for the most) do not consist on simple transactional processes. No single platform or solution will cover it all, neither will such platform be used in complete isolation of any other solution, especially for advanced product engineering and manufacturing. There are multiple schools of thought in terms of adopting PLM processes:
- The minimalist approach which involves keeping the level of adaptation to the strict minimum and adapting working practices and methods to what’s in the box (as close as possible to the out of the box, or OOTB, process)—with sale slogans such as “changing the process, not the tool.” This rarely applies to everything and is therefore either temporary, of limited scope, or not intended to scale (see Myth 4 above).
- The tailored approach which implies adapting the toolset to meet specific custom process or data requirements; most platforms offer capabilities to personalize the solutions to the business model that they serve. This can actually be perceived as “thinking-outside-of-the-box.”
Some vendors openly claim that their platform cannot be implemented without customization, whereas others claim that it can be used OOTB—the usual dilemma. Some capabilities are likely to be more customized than other, and differently to for every organization. Like everything with PLM, there are no common ways to assess levels of customization and integration (or lack of). It remains important to consider future maintenance of such alterations and continuously assess potential cost and knowledge implications.
Myth 6: Cloud-Based SaaS Platforms Will Solve All PLM Implementation Challenges
Infrastructure and other IT related benefits are becoming part of the new normal; it is fair to recognized that PLM is finally “catching up with the cloud” which to-date has mainly been the land of ERP, CRM, etc.
PLM in the cloud can mean many things in terms of infrastructure hosting. This includes, although not limited to, two types of cloud-based software-as-a-service offerings:
- PLM SaaS for single tenant: pay for what you use, when you use it—embedding your own processes and enterprise hybrid-cloud integration.
- PLM SaaS with multi-tenants: with added economies of scale when sharing a commonly administrated platform across independent organizations.
SaaS platforms bring the promise to reducing “entry barriers” to PLM adoption, focusing on low cost and future scalability and flexibility. Multi-tenant platforms also have the potential to change the landscape of small and medium enterprises. Start-up and other large enterprises typically require tailored solutions as they aim to scale and optimize operations as they grow or diversify.
Clearly the need for PLM-on-premise is to be challenged; SaaS platforms offer new ways to experiment early and swiftly validate process designs before (or even without) making long-term costly commitments. The need for business change, integration at both process and system level, education, etc. still remain. Other considerations of data migration, integration bottlenecks, and questions of future “transferability” are also to be explored.