Author Copperberg Editorial Team | *This article was developed using a combination of human expertise and AI-assisted writing. The concept, structure, and editorial direction were defined by our team, while elements of the text were generated with the support of advanced language tools. All content has been reviewed, refined, and approved by humans to ensure accuracy, clarity, and relevance.

For many manufacturers, product lifecycle management (PLM) effectively stops at start-up. Engineering and manufacturing enjoy sophisticated tools for design, configuration, and change management — while service teams responsible for the next 10–30 years of equipment life often operate with fragmented systems, static PDFs, and outdated data.

That disconnect is more than an annoyance. It undermines profitability in the very part of the business that typically generates the majority of margin. In many industries, 60% or more of revenue comes from service, with margins far higher than original equipment sales. Yet the digital backbone of product information is still largely designed by, and for, engineering.

A growing number of industrial companies are starting to question this model. At Field Service Forum 2026 – Power of 50, Philippe Bartissol, VP at Dassault Systèmes, shared the emerging view: PLM should no longer be an engineering-owned tool that happens to store some product data. It should be a service-driven backbone that manages the installed base throughout its true lifecycle — from concept to recycling, including decades of field service, retrofits, and decommissioning.

From Engineering-Driven to Service-Driven PLM

Traditional PLM was never designed to extend beyond engineering and manufacturing. Once the machine ships, the L in PLM effectively ends. Service teams then improvise with ERP, CRM, field service tools, and local spreadsheets.

Most organisations still treat ERP as the primary system for managing the installed base. Product identifiers, configurations, and even technical details often end up buried in ERP tables. This creates several issues:

• Product structure and service structure are disconnected.
• Engineering changes are slow or impossible to propagate into service.
• Spare part catalogues drift away from reality in the field.
• Installed base data becomes inconsistent across regions and teams.

The alternative is to treat PLM, including CAD and 3D models, as the backbone not just for new product development, but for the entire life of every asset in the field. In this model, PLM becomes the receptacle of product and service data, and other systems consume from it. The data model extends beyond engineering to describe:

• Physical products (machines, modules, components).
• Service products (contracts, maintenance offerings, retrofits).
• Engineering views and service views of the same asset.
• The actual configuration of each machine by serial number.

Decisions about PLM can no longer be made solely by engineering. Service leaders need to be central to PLM strategy, selection, and governance because their requirements around installed base data, spare parts, and field processes define the majority of the lifecycle.

Engineering View vs Service View: The Twin That Service Actually Needs

Digital twin is often discussed in abstract terms, but for service organisations the concept becomes concrete when you distinguish between two views of the same asset.

An engineering view describes how the product is designed and built: full bill of materials (BOM), all structural parts, design intent, tolerances, and modules. This view is critical for root cause analysis, complex retrofits, and feedback to R&D.

A service view, by contrast, is focused on what actually matters during maintenance and repair. This requires a dedicated service BOM (SBOM) that:

• Includes only spare parts, consumables, and assemblies relevant for service.
• Groups parts into service kits that reflect real field practice.
• Links to service work instructions, tools, and safety information.
• Is tied to the 3D model so technicians and planners can visualise the work.

No development engineer will ever define a practical service kit. Only service teams know which parts are always changed together, what fails in real conditions, and how to minimise site visits. If the PLM does not support a distinct service view with SBOMs, service teams are forced to maintain their own structures and catalogues, disconnected from engineering.

Modern PLM platforms are starting to close this gap by allowing both views to coexist and stay synchronised. During new product development, engineers can define the product structure while service teams define SBOMs, service processes, and 3D-based work instructions in the same environment. Product changes then flow across both views by design.

Extending PLM to the Installed Base

The real test of a service-driven PLM is not how well it supports a generic product, but how precisely it represents each installed asset in the field.

For companies producing a smaller number of highly customised machines, the need is clear: each machine is unique, and service depends on knowing its exact configuration, location, and modification history. In such cases, PLM can now store a specific digital twin per serial number, including:

• Engineering view: the as-designed and as-built structure.
• Service view: the as-maintained SBOM and service kits.
• Location and customer: where the asset operates.
• History: issues, interventions, retrofits, and upcoming activities.

This enables a different way of working. Before a visit, a planner or dispatcher can open an install base cockpit and see the actual twin of the machine at that site, not a generic model, but the specific configuration. They can then select the right spare parts, validate work instructions, and prepare the technician properly.

For high-volume manufacturers, the approach is more selective. Not every unit will warrant a bespoke twin. Instead, the installed base can be segmented into buckets based on data richness and business value:

• Older equipment where only high-level parameters are known.
• Mid-life assets with partial structures and limited documentation.
• Recent installations with complete BOMs and CAD data.

Each bucket is then approached differently: some may justify reconstructing a partial twin; others may be managed at a more generic level. The key is to treat the installed base as a structured portfolio, not a historical accident.

Service-Driven Change Management and Spare Parts

Linking service and engineering inside PLM reshapes change management. In many organisations, when engineering changes a component, service hears about it late, if at all. Spare part catalogues are updated months afterwards, if they are updated at all.

With a shared data model, product changes can cut across engineering, manufacturing, service offerings, SBOMs, and installed base records in a single flow. When a change is approved:

• The engineering view is updated.
• The related SBOMs and service kits are adjusted.
• Spare part catalogue entries are automatically revised.
• Applicable installed assets are identified by serial number.
• Service teams can plan retrofits or proactive replacements.

Crucially, PLM must now include explicit objects for spare part catalogues and their publication, not as external documents, but as structured data tied to the twin. This reduces inconsistencies between engineering drawings, service manuals, and what technicians actually see on site.

Capturing Tacit Knowledge Before It Retires

Another pressure point is workforce demographics. Many field technicians are approaching retirement, and much of their expertise remains tacit: held in individual experience, local notes, and informal practices. Converting that into explicit knowledge is not optional if companies want to maintain service quality and growth.

The question is where that knowledge should live. If every function has its own system of record, field knowledge risks being scattered or lost.

Service-driven PLM offers one answer: embed knowledge directly into the twin as structured data:

• Service processes described step-by-step, often in 3D.
• Tools and conditions required for each operation.
• Practical recommendations codified as work instructions.
• Feedback loops that create issues or change requests when technicians encounter something new.

Artificial intelligence can play a supporting role, but only when the underlying data is structured and reliable. One emerging use case is ingesting technician reports after a visit and automatically proposing updates to the digital twin. A dispatcher or central coordinator then validates the update. Over time, the twin reflects the real state of the asset without demanding extra effort from technicians in the field.

This is more about disciplined data management: consistent models, clear workflows, and defined ownership. Once that foundation is in place, AI can help maintain accuracy at scale with minimal manual intervention.

What Service Leaders Should Do Next

One implication of this shift is that PLM strategy is no longer a back-office engineering concern. It is a core lever for service revenue, profitability, and customer satisfaction.

Service leaders should therefore:

• Insist on being central stakeholders in PLM decisions and roadmaps.
• Define requirements around installed base management, SBOMs, service kits, and work instructions before tools are selected or extended.
• Challenge the assumption that ERP or ad hoc tools are the natural home for product and service data in the field.
• Start with a clear scope: either a new product line that will be managed correctly from day one, or a prioritised segment of the existing installed base where ROI is clear.
• Design processes for how issues in the field trigger structured updates to the twin and, where relevant, to engineering.

The goal is not to rebuild every asset history overnight, but to establish a coherent, service-led digital thread for future growth. Once PLM is extended to cover the full lifecycle — including decades of service, retrofits, and end-of-life — manufacturers can treat service as the primary engine of long-term profitability.