This post follows the publication of a joint white-paper with the Professional PLM Initiative on “PLM in the Digital Future” as an open plea for practitioner feedback.
The future is digital
Simply put, Digital refers to two principles: 1) everything (every “thing” and everybody) is getting digitally connected, and 2) this hyper-connectivity provides opportunities for innovations and new sustainable business models that everyone can benefit from (adapted from WEF, 2019).
The Digital future is not only about adopting technology to improve operations, products, factories, etc. – it concerns how technology is used to extend and create new business value. Nowadays, technology is both the enabler (enterprise platforms) and the end-goal application of products and services (operations technologies). This includes how enterprise platforms are being positioned to support business operations in providing smart automation and connectivity, addressing existing pain points, providing new business capabilities, mitigating business risk, enabling data re-use, data extension and collaboration across the wider product lifecycle (…).
CIMdata defined digitalization as “the business strategy best geared to extract real-world value from digital data”, whereas their definition of PLM refers to a “strategic business approach, NOT just technologies, a consistent set of business solutions”.
CIMdata (2019)
The open question is about which “consistent set of business solutions” or what is sometimes referred as “capabilities” that the business needs to operate – and whether or not it still makes sense to refer to these solutions as “PLM”, “ERP”, “MES”, etc. On the other side of the spectrum, other PLM evangelists suggest that future PLM mothership environment is to cover everything that connects data between virtual and physical worlds, including smart products / services, smart factories / Industry 4.0, smart operations, smart sensors / IIOT, smart everything – an interesting vision, but perhaps also trying to eat all the “cakes” from ERP, MES, IOT, etc.?
Hence the question: where to draw the line to ensure a consistent PLM identity? This is important to help simplify and differentiate the relevant building blocks for each discipline, skills, technology standards and ‘best practices’ to be effectively deployed as part of PLM digital (and associated business transformation) implementations.
The scope of PLM in the digital landscape
In 2015, I noted 19 elements or disciplines under the banner of a ‘periodic table of PLM’; they combined to enable digital business operations primarily across product development and manufacturing engineering (and beyond). Some of these elements could have their data mastered in the ERP side (such as cost typically) and other clearly span across disciplines (such as weight and material management for example).
In recent years, the focus shifted to Model-Based System Engineering (MBSE) and Model-Based Enterprise (MBE), describing feedback loops within and across enterprise operations. This is now also coupled with the concept of digital twins as the virtual representation of the various assets managed by the enterprise. There are numerous digital twin models used in feedback loops across the enterprise, and it would certainly help to define which relate to PLM, ERP or MES, how they aggregate their input and how / where is managed their output in the wider context of model-based everything. This is not just a matter of easing the sales process, but primarily helping business leaders to understand the potential value and ROI of these models, how they fit in the wider operating landscape – controlling data duplication and, as CIMdata put it, the potential “proliferation of digital platforms” within a single organization. This reinforces the need for a clear PLM identity and standards to avoid costly mistakes or duplication in implementations, and having to repeatedly sew, un-sew, re-sew the digital thread.
Modern enterprise platforms go beyond PLM
Debating the place of Product Lifecycle Management (PLM) in the wider Digital context does not reduce PLM as a toolset or technology. On the contrary, it aims to clarify its “identity” or scope across the business operating landscape and the technology stack.
In an industry context, enterprise platforms clearly appear to have overgrown what used to be called PLM, ERP, MES, CRM, etc. the so-called “PLM vendors” are no more “just about PLM”. Their integrated platforms now serve multiple purposes and cover wider business capabilities, whereas PLM (perhaps arguably) still relates to a specific purpose: a strategy to manage the entire product lifecycle (from ideation to end of life).
- The overlaps between PLM and ERP and their interfaces are various and essential commodities to manage data within or across such operating platforms.
- PLM and ERP feed data to MES (with a number of feedback loops) to enable factory assembly line operations.
- CRM provides a strategy for customer information management, whereas supplier and selected customer information is also managed (or retrieved from) within the PLM, ERP and MES spaces.
In 2015, I had suggested that PLM is itself an operating model acting as the “glue” between digital product engineering, digital manufacturing, project engineering and execution – augmenting human creativity, enabling faster product creation and innovation. Assuming this definition stands, it perhaps implies that the PLM “footprint” is primarily aimed at product development and digital manufacturing. This footprint extend / interface to asset management in operations (in-field activities such as maintenance, service, optimization, etc.). Asset performance management is a broader subject as it covers both the product, production and maintenance equipment—which in turn have their own lifecycle. Taking the view of data business ownership and I/O mastership can help draw the secondary footprint of PLM data downstream and upstream its primary footprint—likely to be another open debate…
For example, the service BOM is clearly part of the lifecycle of a product; it interfaces with the other bills of materials. Manufacturing or service driven product enhancements will feedback change requirements into the product development cycle, but is the SBOM actually part of the PLM discipline?
Digital future
Enterprise platform proliferation bring opportunities for digitalization like never before, with ever-expanding scope and business overlaps, proving both industry generic and industry specific capabilities. Enterprise platforms are not only about tools and technologies; hence it is not a debate about whether there is more or less “PLM” or “ERP” in one platform or another (as provided by one vendor or another) but rather:
- What data set is mastered where (it could be a number of databases or files, this is not about having a single system, but a clear original source of authoring for each data set).
- How data mastership evolves / changes throughout the product or service lifecycle (i.e. as one data set matured, it is combined with other data sets and transformed from its original purpose to a new purpose).
- How data set are combined to support business capabilities (e.g. product development, service execution, etc.).
- How platforms are integrated within their own components and between themselves, how data is sewed across the digital thread, and what interfaces enable this and how open / agile are these data models and connections.
- Etc.
Master data discussions considerations also link to data models, database and infrastructure / cloud architectures which are clearly part of the Digital debate. The point is not to look at system architecture as the main driver for this debate as the PLM identity should not be based on how many databases or the type of cloud on which the underlying systems are stored. It is also not about the number of systems and interfaces: most enterprise platforms are actually a collection of systems with often limited “under the hood” access. Nevertheless, core principle and evolution agility of these platforms are important implementation factors.
Similarly, for some PLM evangelists the “single source or truth” principle seems outdated, whereas (to my mind) it did not refer to a single system of record, it is rather about clear data mastership management.
To illustrate this:
- If during the design phase of a product, system A is the master for “surface data”, then subsequent surface changes which relate to changing the design of the product should be done in system A (authoring system).
- Such surface data might then be transformed to engineering CAD parts in system B downstream of system A.
- System B is then the master for engineering CAD part update (unless the engineering change implies a significant Fit-Form-Function / design change that might require an upstream change in system A)—hence the importance of data and change process governance.
- System A might be built with two databases, one in the cloud and one on-premise—this is not the point.
- Also, both systems A and B might be part of the same platform umbrella, but again this is not the point of this debate (however for sure a key point when implementing the solution).
Enterprise platforms have perhaps diluted their specific “purpose” by aiming at integrating all operations under a holistic umbrella as it is perhaps the vision for a fully connected Digital future; vendors are also keen to continue to grab new digital real-estate markets. This should not be an excuse to dilute the meaning of PLM, ERP, MES, etc. but perhaps on the contrary, time has come to clarify (and simplify) these disciplines and their respective roles in the Digital future.
This is the premise outlined in an initial white-paper presented in collaboration with the Professional PLM Initiative—please share your views; all feedback is welcome, even if we don’t agree 🙂
What are your thoughts?
References:
- This is the digital future we need (World Economic Forum, 2019)
- Digitalization, Digital Thread, PLM & MBSE: Where to next? (CIMdata, 2018)
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
