Product Lifecycle Management – Turning the digital thread ...

Full announcement (unchanged)

A business-led, value-first perspective on PLM transformation spanning the operating model, product data, enterprise architecture, AI, governance, and adoption. Introduction: PLM as an enterprise value system Product Lifecycle Management (PLM) is often positioned as an engineering system. Its strategic value is much broader: PLM is the operating backbone that keeps product definitions, configurations, changes and lifecycle evidence coherent as decisions progress from requirements and design through sourcing, manufacturing, quality, service, and end-of-life. PLM should be managed as an enterprise operating model for product information and change — not as a repository project owned solely by engineering or IT. A digital thread exists only when product information remains trustworthy across organisational and system boundaries. NIST describes the digital thread as connecting lifecycle information across design, manufacturing and product support, while noting that one-way flows and information gaps still limit enterprise-wide use. [1] The practical challenge is therefore not simply to install a PLM platform. It is to determine which information is authoritative, who owns it, how change is approved, and how released information reaches the functions that create customer value. This Point of View brings business value, the operating model, processes, product data, architecture, integration, AI, governance and organisational change into a single transformation agenda. It is designed to support leadership discussions around three questions: Where does lifecycle value or continuity break down? Which decisions must be made before selecting or configuring technology? How will the programme demonstrate measurable outcomes rather than activity? Figure 1. Anatomy of a well-integrated PLM landscape: value chain, systems and data flows Why PLM matters now — and how it creates value Rising product complexity and software content, global supply networks and shorter release cycles increase the cost of disconnected product decisions. When requirements, bills of materials, documents, variants, effectivity rules and changes are interpreted differently across functions, the consequences include rework, late releases, manual reconciliation, excess variants, production disruptions and weak auditability. The business case for PLM starts with these operational breakdowns — not with licence features or market-growth statistics. Regulatory pressure also increases the value of governed lifecycle evidence, although applicability must always be confirmed for the client’s products. The EU Ecodesign for Sustainable Products Regulation establishes the framework for eco-design requirements and the Digital Product Passport. The 2025–2030 working plan identifies priority product groups, while product-specific measures define the detailed obligations. [2][3] The Cyber Resilience Act introduces lifecycle obligations for products with digital elements; Article 14 applies from 11 September 2026 and most provisions from 11 December 2027. [4] Five value mechanisms Speed. Trusted requirements, reusable product definitions, and controlled-release workflows can reduce the lag between an engineering decision and an executable release. Relevant measures include idea-to-release time, engineering change cycle time, and on-time release performance. Quality. Clear lifecycle states, complete product structures and closed-loop change can reduce avoidable rework and improve first-time-right release performance. Evidence should come from deviations, non-conformance records, engineering hours and audit findings. Cost and cash. Better classification, part reuse, variant control, and effectivity management can lower material costs, scrap and obsolete inventory. ERP costing, inventory, and production history are the primary sources of evidence. Risk and compliance. Traceable product identity, configuration and approval evidence improve audit readiness and make security- or compliance-relevant changes easier to govern. The benefit must be risk-adjusted and linked to the applicable obligation. Growth and service. Configurable offers, reliable installed-base information and closed-loop service feedback can support faster quotations, greater content reuse and better product decisions. These outcomes depend on effective connections between PLM, CPQ/CRM and service systems. Commercial objectives must govern PLM scope and data A PLM programme that is scoped around available systems, existing product data, or software capabilities tends to grow into a parallel database exercise: comprehensive, well-structured, and disconnected from the commercial result it was meant to improve. The value mechanisms described above — speed, quality, cost and cash, risk and compliance, growth and service — only become a business case when they are translated into a small number of named, client-specific commercial objectives before data collection, modelling or system design begins. Benefit-realisation research on PLM programmes confirms that return on investment typically remains theoretical until it is anchored in a defined KPI methodology linked to measurable business performance. [10] Scope should follow the objective, not the other way round. If the commercial goal is faster, more accurate quotations, the programme should prioritise configurable product structures, pricing-relevant attributes, and the CPQ/CRM interface — and defer product domains that do not serve that goal, however complete they may be. If the goal is lower warranty cost, the priority is installed-base identity, as-maintained configuration and the service feedback loop, not a broader data model pursued for its own completeness. Three disciplines keep the programme commercially anchored Name the commercial objective first. Before any data domain, object type or integration is scoped, agree two to four measurable commercial outcomes — for example, quote-to-order cycle time, win rate on configured offers, warranty cost per unit, or on-time delivery of profitable variants — and the business owner accountable for each one. Let objectives prioritise the backlog. Data domains, system integrations and AI use cases compete for the same delivery capacity. Rank them by their contribution to the named commercial objectives, not by technical feasibility or data availability, so that the easiest data to collect does not quietly become the programme’s real priority. The same discipline applies to data governance more broadly: linking governance and data-quality investment directly to priority business use cases, rather than pursuing data quality as a general good, is what separates data initiatives that demonstrably reduce cost from those that do not. [11] Gate investment on commercial evidence, not on functionality delivered. At every value gate in the roadmap below, the sponsor should ask what the released capability changed in the commercial metric it was funded to move — cycle time, win rate, warranty cost, margin — rather than how much of the product model or how many interfaces were completed. Without this discipline, a PLM investment can accumulate governance, data quality, and system capability while leaving the commercial result unchanged — comprehensive, well-governed activity around a product database that is never tied back to a commercial decision. Treating commercial objectives as the starting constraint, not a benefit realised afterwards, is what keeps PLM a business investment rather than a data-management exercise. The foundation: operating model, processes and product data PLM transformations underperform when the programme is framed as a system-configuration exercise. Although no universal failure-rate statistic applies, the recurring patterns are consistent: unclear outcomes, weak data governance, underestimated adoption, and missing cross-functional ownership. These patterns matter because technology cannot decide the organisation’s product policy, data ownership or approval rights. A single source of product truth does not mean that one application owns everything. It means that every object, attribute, and lifecycle event has one agreed-upon source of record, an accountable owner, and a hand-off rule. The target operating model begins with clear decision rights. Executive leadership owns outcomes, investment and risk. Process and data owners define lifecycle policies, standards and exceptions. Engineering, manufacturing, quality, supply chain, service, IT, architecture, and security participate in a single governance model. Programme leadership translates these decisions into executable releases, while the run organisation owns support, backlog, data quality and realised value after go-live. The core process scope normally includes portfolio and requirements management, product definition, lifecycle and release, engineering change, configuration management, manufacturing collaboration, quality and compliance, and service and end-of-life feedback. The exact boundary is client-specific and should be drawn around the decisions that require shared information and control — not around an assumed list of software modules. Designing product data is therefore a business task. The programme must define item and document types, identifiers, classifications, relationships, variants, versions, revisions, maturity states and effectivity. It must also decide how EBOM information becomes MBOM/BOP content, how software and hardware configurations relate, and which evidence must be retained for approval, compliance and long-term use. ISO 10303-242:2025 provides a standards-based route for managed model-based 3D engineering and neutral exchange where interoperability or durable records are required. [5] Migration should be managed as a governed data product, not left as a late technical work package. Discovery, scope decisions, cleansing, transformation, validation and cutover require named business owners. After go-live, the same ownership continues through measurable data-quality controls: completeness, validity, uniqueness, consistency, relationship integrity, lifecycle correctness and interface reconciliation. ISO 8000-150:2022 reinforces the need to establish and document data-quality roles and responsibilities. [6] Architecture and integration: making the digital thread work A credible PLM architecture separates system capability from information ownership. PLM typically governs technical product structures, engineering documents, configurations, lifecycle states and engineering change. ERP typically governs commercial material records, procurement, inventory, costing, planning, and financial transactions. MES/MOM governs executable production instructions, as-built records, genealogy and shop-floor execution. QMS controls quality processes and evidence, while CRM, CPQ, and service platforms connect the product definition to customers and the installed base. These are starting assumptions, not universal rules. A platform may be technically capable of storing the same object as another system, but capability alone does not settle the source-of-record decision. SAP’s official PLM System Integration documentation shows that external PLM and SAP S/4HANA can exchange change objects, document and product versions, product structures with effectivity, and production operation lists. [7] The client must still decide ownership, release triggers, transformation rules, and reconciliation controls for every hand-off. Six controls for dependable integration • Source of record. Name the authoritative system for every object and attribute, including identifiers, units, classification, and ownership. • Lifecycle trigger. Define what is transferred, when, at which revision and with which effectivity after approval or release. • Transformation. Make the EBOM-to-MBOM/BOP transformation logic, material creation, and manufacturing-specific enrichment explicit and accountable. • Reconciliation. Monitor acknowledgements, errors, replay controls, duplicate prevention and end-to-end record counts as an operational process. • Security. Enforce intellectual-property segmentation and existing user access rights across internal and external collaboration. • Closed-loop feedback. Feed manufacturing, quality, service and connected-product evidence back into product decisions without creating uncontrolled shadow records. Architectural success is not measured by the number of interfaces delivered. It is measured by whether a released product definition moves into execution once, with traceable transformation and controlled exceptions, and whether downstream evidence improves the next product decision. Integration ownership, monitoring and service management must therefore continue after implementation. AI-enabled PLM: value depends on the foundation AI does not compensate for weak product data. It increases the value of a governed digital thread — and can amplify inconsistency, access mistakes and untraceable decisions when the foundation is weak. Promising use cases include semantic product and document search, requirements quality analysis, part similarity and reuse, BOM and cost analysis, engineering change impact assessment, compliance evidence preparation, MBOM/BOP assistance, and service feedback analysis. These are value hypotheses, not statements that every PLM platform provides the capability or that every client will achieve the same result. Each use case needs a defined user task, baseline, owner, approved data sources and a measurable acceptance test. The NIST AI Risk Management Framework is voluntary, and structures risk work through Govern, Map, Measure and Manage. Its Generative AI Profile provides cross-sector guidance on risks that are unique to or intensified by generative AI. [8][9] For PLM, this means defining approved knowledge, enforcing existing access rights, evaluating answer quality and traceability, keeping human approval for safety-, compliance-, release- and material-change decisions, and monitoring exceptions after deployment. Figure 2. AI use-case prioritisation A credible starting point is a measurable user task and a client-specific baseline. Where the evidence is insufficient, a Proof of Value should test the hypothesis before wider investment. Outputs should be grounded in approved PLM content, linked back to their source objects or documents, and evaluated for accuracy, completeness, traceability, latency, adoption, and operating cost before scaling. The matrix translates this principle into a portfolio view. Its vertical axis represents the potential impact of a capability on a defined user task or business decision; it does not represent guaranteed financial return. Its horizontal axis represents the maturity needed across product data, metadata, integration, workflow, identity, access, traceability and human control before the output can be trusted in daily work. The table explains the positioning in practical terms. Capabilities move to the right when they depend on more systems, more complete lifecycle relationships or higher-consequence decisions. They move upward when they can influence the speed of material release, engineering effort, production readiness, cost, compliance, or product learning. The positions are Midagon hypotheses for client discussion and should be adjusted when the client’s process scope, data condition, risk profile or available technology changes the evidence. Figure 3. Some AI use-case Governance, organisational change and adoption PLM changes how functions define, approve, release and reuse product information. It therefore changes decision rights, roles and day-to-day work — even when the user interface looks familiar. Treating change management as training delivered near go-live leaves the hardest questions unresolved: which local practices will stop, who may approve exceptions, how new data ownership will be enforced and how leaders will respond when adoption falls. Governance should operate across five connected levels. Executive steering owns outcomes, scope, investment and risk. A process and data council owns standards, lifecycle policies, data ownership and cross-functional exceptions. Programme leadership owns the plan, dependencies, delivery quality and issue resolution. Release readiness brings business, data, solution, integration, security, learning and cutover acceptance into a single gate. The run-and-improvement model owns support, backlog, product ownership and realised value. What adoption looks like in operations Engineering change. Changes are routed and approved against agreed service levels, with downstream impacts on cost, inventory, production and compliance visible before approval. Product-data quality. Completeness, BOM integrity, lifecycle correctness, and reconciliation exceptions are continuously monitored, with named owners and visible queues. Release rhythm. Engineering, manufacturing, quality and supply chain run cross-functional release reviews on a fixed cadence rather than resolving every issue through email or local files. Leadership cadence. Sponsors continue to review release performance, rework, data quality, adoption and realised benefits after go-live — not only budget and schedule during implementation. Change should begin with the future operating model and stakeholder impacts, continue through co-design and role-based learning, and remain visible through hypercare and stabilisation. Super users and local leaders are important, but they cannot compensate for unclear executive decisions. The sponsor must make the new process the default way of working: decisions, approvals, evidence and performance reviews should move into the governed operating rhythm. A delivery roadmap that releases value in stages A PLM transformation should progress through explicit decisions and value gates. Midagon structures the journey as Define, Plan, Execute and Stabilise. Programme management, the business case, dependency management, organisational change, data governance, security and service design run across every phase. The logic is consistent; timing and release design depend on scope, sites, the legacy landscape, data condition and vendor readiness. Define Align outcomes, establish current performance baselines, map the capability and system landscape, diagnose data and adoption readiness, frame the scope, and prepare the initial business case. Exit at an investment gate with an accountable sponsor, priority value streams and a decision plan. Plan Design the target operating model, process and data architecture, integration principles, security and service model. Select the solution and delivery partner where required, convert the roadmap into a contracted delivery plan and mobilise governance, resources, and dependencies. Execute Deliver coherent value-stream releases iteratively, combining process, configuration, integration, data migration, testing, learning and operational readiness. The release gate accepts the combined business, data, solution, security, integration, and cutover outcome. Stabilise Run hypercare, transfer ownership to the service organisation, stabilise support and data-quality metrics, verify adoption, and continue benefit tracking. The value gate closes only when ownership is active and continuous improvement is embedded in normal portfolio governance. Do not measure progress by configured functionality alone. Each release should demonstrate adopted processes, governed data, effective integration controls and measurable business impact. A successful PLM transformation goes beyond system go-live: it enables faster, better-controlled product decisions and sustained value throughout the product lifecycle. Turning the Point of View into a client conversation Before this conversation turns to a target platform, it is worth returning to the commercial discipline set out earlier in this Point of View: the questions below work best once two to four named commercial objectives, and their accountable owners, are already agreed. Without that anchor, even a well-run assessment risks cataloguing data and process gaps rather than prioritising the ones that move a specific commercial result. The first conversation should identify where value, continuity or control breaks down before discussing a target platform. A focused PLM value and readiness assessment can align outcomes, diagnose the current operating model, establish architecture principles, prioritise value streams and AI opportunities, and mobilise the next decision. The output is a fact-based decision pack — not a generic maturity score. Questions that expose the real transformation agenda • Where does product information lose continuity or trust between requirements, design, sourcing, manufacturing, quality, service and end-of-life? • Which release or change decisions still depend on spreadsheets, email or local files — and why? • Who owns requirements, EBOM, MBOM/BOP, material master, configuration, effectivity and compliance evidence? • How is engineering-change impact assessed across cost, inventory, production, compliance and the installed base before approval? • Which PLM–SAP–MES/MOM–QMS hand-offs create re-entry, reconciliation failures or late releases? • Which baseline measures are trustworthy enough to support an investment decision? • Which AI use case helps users complete a specific task using approved product data they are allowed to access? Why Midagon Midagon provides independent transformation leadership across business, engineering, operations, IT, data and the vendor ecosystem. Because Midagon does not sell PLM software licences, recommendations remain anchored in the client’s business value, target operating model, enterprise architecture, delivery risk and long-term service model. Midagon can support the full journey: before funding through a value and readiness assessment; before selection through requirements, architecture, RFI/RFP and contracting support; during implementation through programme leadership, design authority, data and integration leadership, testing, change and cutover; and after go-live through stabilisation, adoption recovery and continuous-value governance. The customer remains accountable for business decisions and outcomes, while the systems integrator remains accountable for contracted solution delivery. References [1] NIST — Digital Thread for Smart Manufacturing [2] Regulation (EU) 2024/1781 — Ecodesign for Sustainable Products Regulation [3] European Commission — ESPR and Energy Labelling Working Plan 2025–2030 [4] Regulation (EU) 2024/2847 — Cyber Resilience Act [5] ISO 10303-242:2025 — STEP AP242, managed model-based 3D engineering [6] ISO 8000-150:2022 — Data quality management: roles and responsibilities [7] SAP — PLM System Integration 3.0 for SAP S/4HANA, FP02 [8] NIST — AI Risk Management Framework 1.0 [9] NIST AI 600-1 — Generative AI Profile [10] Alemanni, Grimaldi, Tornincasa, Vezzetti — Key performance indicators for PLM benefits evaluation: The Alcatel Alenia Space case study, Computers in Industry, Vol.