A couple of months ago I gave a talk at an industry conference. During a break, a woman that, as it turned out, had heard me speak before and is a regular reader of my blog, commented, “It seems you don’t do PLM anymore.”
I guess she was right. It does appear that over the last several years I wrote and spoke about PLM topics much less than I used to a few years back. And here is why.
Product companies use product lifecycle management software to manage product variants and bills of material. To a lesser extent, PLM is used by product teams to manage and track product development cycles and transition to manufacturing workflows. Product companies of any size find PLM software highly useful to manage the design and fabrication of products that range from simple consumer products to the F-35 Joint Strike Fighter.
The aspiration of PLM software advocates is to manage complex products from cradle to grave by integrating data, workflows, and information systems across the entire span of the value chain. The goal is to allow value-chain participants frontload complex multidisciplinary decisions and optimize product-related decisions for the duration of the product’s useful life. I am making this sound complex on purpose, but it does not have to be. Here is an example.
Design for service (DFS) is the practice of incorporation serviceability metrics, such as repair time and cost, into early product lifecycle phases. Doing so ensures that the product architecture is optimized not only for its intended functionality but also for field service: field-replaceable units, diagnostic tools, part inventory management and so forth. DFS is an exercise in harmonizing potentially conflicting design and operations goals such as cutting product cost to be more competitive against the potential penalty of longer and costlier warranty repairs.
By surfacing all competing lifecycle considerations early and make necessary changes and allowances before a design is complete and frozen, stakeholders have greater flexibility to make design decisions at much lower cost.
DFS is a good example of this type of tradeoff analysis. It is also a good example of an engineering design practice that isn’t employed often enough.
The Blind Men and an Elephant
The nature of PLM and the notion of frontloading multi-domain decisions means that at any point in the product lifecycle, multiple stakeholders must come together and try to harmonize competing functional and operational goals. PLM diehards see the role of PLM software as the keeper of a “single version of the product truth” that gives individual stakeholders complete and objective product information curated exclusively for their function-specific role and information needs.
But the notion of single version of truth is often challenged by the fact that stakeholders come into these sessions informed by practices and methods that are unique to their business function. Simply stated, a mechanical engineer may not recognize serviceability indicators in simulation results or early quality reports. Similarly, service planners aren’t necessarily conversant in the intricacies of design and manufacturing. In short, individual value chain participants may use the very same data set to reach different conclusions.
So instead of being an information system responsible for the single version of the truth, PLM resembles the blind men and the elephant. In this ancient Indian parable, each blind man feels a different part of the elephant’s body, such as the side or the tusk. They then describe the elephant based on their limited experience and their descriptions of the elephant are different from each other.
PLM vs. the Value Chain
In some respect, the PLM message and the value-chain philosophy exercised in many organizations are incompatible. Value-chain practices emphasize local optimization of each function before its output is handed over to the next value chain function. Referring back to the DFS example, a common practice in many organizations is to complete most of the design before service designers get involved, at which point making major change is prohibitive. The vision of single version of truth and frontloading decisions is often incompatible with organizational knowledge processes and workflows.
Thankfully, this rigid thinking is changing. Product companies are adopting agile development practices across many engineering disciplines, not only software, and encourage rapid iterations to assess the impact of decisions on downstream.
The Connected Enterprise
The connected enterprise is changing the way in which stakeholders receive, perceive and act on information: the industrial Internet of Things provides detailed real time data from fielded devices; digital twins, simulation software and predictive analytics provide rich and objective insight; and a digital thread connects traditionally disparate enterprise systems such as ERP, PLM, MES and field service.
The connected enterprise enables each stakeholder analyze data from many relevant sources, develop solution and conduct impact analyses that address all product lifecycle functions and phases and drive better decisions as early as possible.
I find it fascinating that traditional PLM software vendors are not realizing how the Internet of Things and the connected enterprise are breathing a new life into the PLM space that does not quite know how to reinvent itself. After decades of using enterprise PLM software, it is still common to hear at a PLM conference a speaker announcing, “Let me give you my definition of PLM.” Or those never-ending debates about eBOMs and mBOMs and where PDM ends and PLM begins. And, of course, there’s the tried and true cliché: “it’s a journey” (translation: “Leave me alone; I’ll get back to you when I’m done.”)
The irony is that software vendors such as SAP and Oracle that have much to offer in terms of rich data repositories fail to leverage these strengths against the PLM market share leaders: Dassault Systemes, PTC and Siemens.
And PLM vendors that have powerful data collection, delivery and analysis tools continue to gravitate towards technologies and prefer to focus on the minutia of the Internet of Things and augmented reality rather than on the central role of PLM in the enterprise digital backbone.
So, Do I “Do” PLM?
After reading this article, I think you’d agree that I actually do “do” product lifecycle management even if I don’t use the term PLM that often.