1. Foundations and Scope of Product Lifecycle Management

Introduction and Context

A product is never merely a physical object. It is the outcome of decisions concerning customer needs, technology, materials, processes, regulations, cost, service, and eventual retirement. A vehicle, aircraft component, medical device, industrial machine, or consumer appliance passes through many organizational boundaries before it reaches a user. Engineering creates its definition, procurement secures resources, manufacturing transforms designs into products, marketing creates market presence, service organizations support use, and end-of-life processes manage withdrawal, reuse, recycling, or disposal. Product Lifecycle Management (PLM) provides an organizing philosophy and digital discipline for managing this extended product journey.

PLM is concerned with the integrity, accessibility, control, and use of product-related knowledge throughout the product’s life. It is therefore broader than a software application and more specific than a general information-technology strategy. A successful PLM initiative aligns people, processes, information, and technology so that the organization can make better product decisions and preserve a reliable product memory.

The importance of PLM is particularly evident in industries characterized by complex products, long development cycles, high regulatory exposure, extensive supplier networks, and expensive engineering changes. Aerospace, automotive, medical equipment, industrial machinery, shipbuilding, energy systems, and high-technology manufacturing all depend on the ability to coordinate product definitions across functional and organizational boundaries. Even relatively simple products increasingly require traceability of materials, sustainability data, software versions, supplier information, and customer-specific configurations.

This chapter establishes the conceptual foundation for studying PLM. It explains the vocabulary of the field, traces its evolution, presents its principles and lifecycle stages, examines its business value, and distinguishes PLM from closely related enterprise systems. The distinction is essential: many organizations purchase a system described as PLM but fail to achieve value because they treat it as a document repository rather than as an enterprise approach to product knowledge and decision-making.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Define Product Lifecycle Management and explain its scope.

2. Describe the evolution from engineering data management to contemporary PLM.

3. Explain important PLM concepts, terminology, principles, and lifecycle stages.

4. Relate PLM to product development, manufacturing, service, sustainability, and business strategy.

5. Distinguish PLM from PDM, ERP, MES, SCM, CRM, and asset management.

6. Analyze the organizational, technical, governance, and ethical challenges of PLM adoption.

7. Evaluate how digital thread, digital twins, cloud platforms, analytics, and artificial intelligence influence PLM.

8. Apply PLM concepts to an industrial product-development situation.

The Central Idea: Managing the Product as a Continuing Information System

PLM can be defined as an integrated business and information-management approach for governing a product and its associated data, processes, and decisions from initial concept through development, production, use, service, modification, and retirement. The definition contains three important ideas.

First, PLM manages the product, not only the documents associated with it. A drawing, bill of materials, simulation result, inspection report, software file, supplier specification, and service bulletin are meaningful because they describe or control some aspect of a product. PLM connects these objects to product structures, configurations, projects, requirements, changes, and lifecycle states.

Second, PLM is lifecycle-wide. The product is not considered complete when it leaves the factory. Field performance, warranty data, maintenance history, regulatory changes, and customer feedback may lead to redesign or a new product generation. Decisions made during design influence manufacturing cost, reliability, maintainability, energy consumption, and end-of-life impact. PLM creates the basis for considering these consequences early.

Third, PLM is socio-technical. Technology is necessary for managing large volumes of information, but technology alone cannot resolve ambiguous ownership, uncontrolled terminology, poor processes, or conflicting incentives. PLM requires governance: agreement about who may create, approve, change, release, use, and retire product information.

A useful conceptual expression is:

PLM value = trustworthy product information + coordinated lifecycle processes + accountable decision-making.

This is not a mathematical formula but a management proposition. If any element is weak, the value of the system declines. Accurate data without a disciplined process may remain unused; a good process without trustworthy data creates false confidence; and both are ineffective when responsibilities are unclear.

Terminology for a Shared Product Language

A common vocabulary is indispensable because PLM crosses engineering, operations, commercial, and service functions.

Product definition refers to the complete technical and functional description of a product, including geometry, materials, specifications, performance requirements, software, interfaces, and approved configurations.

Product data includes structured and unstructured information about the product. Structured data may include part numbers, revision identifiers, quantities, effectivity dates, and relationships. Unstructured data may include reports, photographs, emails, and maintenance instructions.

Product structure represents the relationships among assemblies, subassemblies, parts, documents, software, and other objects. A product structure may be organized according to design, manufacturing, service, or functional views.

Bill of Materials (BOM) is a structured list of components required for a product or assembly. An engineering BOM describes the design view, while a manufacturing BOM is organized for production. A service BOM supports maintenance and replacement activities. These views must be reconciled without assuming that they are identical.

Configuration is a defined combination of product elements and options. Configuration management controls the identity, status, and relationships of these elements so that the organization knows what was designed, produced, delivered, and serviced.

Revision identifies a successive state of an information object, such as a drawing or specification. A revision does not necessarily mean that the physical product has changed; effectivity and release status determine applicability.

Lifecycle state describes the controlled status of an object, such as preliminary, under review, approved, released, obsolete, or archived.

Change management is the disciplined evaluation, authorization, implementation, and verification of modifications to product definitions or related processes. Engineering Change Requests, Engineering Change Orders, and deviation or waiver records are common instruments.

Effectivity specifies where and when a product definition or change applies. It may be based on serial number, lot, date, model, customer, location, or production event.

Traceability is the ability to follow an item, material, decision, or requirement through relevant lifecycle events and records.

Product genealogy is the historical record of how a particular product or unit was configured, manufactured, inspected, delivered, modified, and serviced.

Digital thread is the connected flow of product information and relationships across lifecycle stages and organizational systems. It emphasizes continuity and context rather than merely the existence of separate databases.

Digital twin is a digital representation of a physical product, process, or system that is linked to relevant data over time. A digital model created before production is not automatically a digital twin; linkage to an actual physical instance and its behavior is important.

Single source of truth means that authorized users rely on a governed, authoritative representation of a particular fact or object. It does not necessarily mean that all data must be stored in one database.

From Engineering Files to Enterprise PLM

The historical development of PLM reflects the increasing complexity of products and collaboration.

In early industrial practice, product knowledge was largely contained in paper drawings, specifications, engineering notebooks, and manufacturing instructions. Control depended on physical filing systems and personal expertise. As computer-aided design became widespread, organizations gained digital models but also encountered new problems: duplicated files, inconsistent revisions, difficult retrieval, and uncertainty about which representation was authoritative.

Engineering Data Management systems emerged to control files and access. Product Data Management expanded this capability by managing CAD files, documents, metadata, revisions, workflows, and relationships among engineering objects. PDM addressed a critical problem—engineering information control—but its emphasis was often limited to the design office.

As organizations recognized that manufacturing planning, procurement, service, quality, and compliance also depend on product definition, the scope broadened. PLM connected product data management with requirements, systems engineering, project management, manufacturing planning, supplier collaboration, service information, and lifecycle feedback. Contemporary PLM may include cloud-based collaboration, model-based systems engineering, simulation management, software and electronics data, sustainability attributes, and analytical services.

This evolution should not be understood as a simple replacement of one system by another. PDM remains an important capability within many PLM architectures. Similarly, PLM does not eliminate ERP, MES, CRM, or SCM. Instead, PLM establishes governed product knowledge and exchanges appropriate information with these systems.

Lifecycle Thinking and the Product Lifecycle

There is no universal lifecycle model applicable to every industry, but a useful generic sequence contains the following stages.

Opportunity and Requirements

The lifecycle begins with a customer need, market opportunity, regulatory requirement, technology possibility, or strategic objective. Requirements engineering translates these drivers into measurable statements. At this stage, organizations should identify stakeholders, intended use, operating environment, safety expectations, cost targets, sustainability objectives, and constraints. Poorly understood requirements create downstream ambiguity that no software can fully correct.

Concept and Feasibility

Alternative concepts are generated and assessed against requirements, technical feasibility, commercial potential, risk, and lifecycle consequences. Trade-off studies, functional architectures, preliminary simulations, and prototypes support decisions. PLM can preserve the rationale behind the selected concept, not merely the final CAD model.

Detailed Development and Validation

The selected concept is transformed into detailed product definitions. This stage may involve CAD, CAE, electronics design, embedded software, tolerance analysis, design reviews, testing, verification, validation, and regulatory evidence. Requirements must be linked to design elements and test results where appropriate. Configuration management becomes increasingly important because numerous teams may work concurrently on interdependent elements.

Industrialization and Production

The product definition is translated into manufacturing processes, tooling, work instructions, inspection plans, process capability requirements, and supplier specifications. The engineering BOM may be transformed into one or more manufacturing views. Changes must be coordinated so that released product information, production planning, quality controls, and shop-floor instructions remain consistent.

Distribution and Delivery

The organization manages packaging, logistics, market-specific configurations, installation information, certificates, and customer-specific documentation. Effectivity is important when different configurations are shipped to different customers or regions.

Operation, Service, and Support

During use, products generate performance, maintenance, warranty, failure, and customer feedback data. Service organizations need accurate as-maintained configurations and instructions appropriate to the actual product. Field information can support reliability improvement, preventive maintenance, safety actions, and future design decisions.

Modification, Reuse, and Retirement

Products may be upgraded, refurbished, remanufactured, repurposed, dismantled, recycled, or withdrawn. End-of-life information includes material composition, hazardous substances, disassembly instructions, ownership transfer, and regulatory records. Circular-economy strategies make this stage increasingly significant.

The stages overlap. Design decisions may continue during production, and service findings may initiate a new development cycle. PLM therefore supports feedback loops rather than a purely linear sequence.

Principles That Give PLM Its Discipline

Several principles distinguish mature PLM from uncontrolled information storage.

Product-centricity means that information is organized around products, configurations, requirements, and lifecycle relationships rather than isolated departmental files.

Controlled change recognizes that change is necessary but must be evaluated for technical, economic, safety, regulatory, and operational consequences. A rapid change that creates production disruption or service confusion is not necessarily beneficial.

Configuration integrity requires the organization to know which definition applies to each product instance, customer, date, and operating condition.

Traceability and accountability require records of origin, approval, effectivity, and use. Every important decision should have an identifiable owner and an appropriate level of evidence.

Reuse of knowledge seeks to prevent unnecessary reinvention. Approved components, design patterns, requirements, test procedures, and lessons learned can reduce cost and development time, provided that reuse is technically appropriate.

Cross-functional collaboration acknowledges that product decisions are jointly shaped by engineering, manufacturing, supply chain, quality, finance, service, customers, and regulators.

Security by design protects intellectual property, personal information, safety-critical data, and commercially sensitive supplier or customer information. Access should be based on role, purpose, and need.

Lifecycle optimization evaluates decisions beyond the development phase. The least expensive design to manufacture may not be the least expensive to own, maintain, or dispose of.

PLM and Related Enterprise Systems

Confusion among enterprise systems is a frequent source of failed implementations. The systems may exchange information, but their primary purposes differ.

PLM and PDM

PDM is primarily concerned with controlled management of product data, documents, structures, revisions, and engineering workflows. PLM includes PDM capabilities but extends across the full product lifecycle and the wider organization. PDM can be viewed as a foundational technical capability; PLM is the broader operating model and information environment.

PLM and ERP

Enterprise Resource Planning manages enterprise transactions and resources such as finance, purchasing, inventory, orders, costing, and production planning. PLM manages the evolving product definition and associated lifecycle knowledge. ERP may require an approved BOM, item master, or manufacturing routing from PLM. PLM does not normally replace financial ledgers or transactional inventory control.

PLM and MES

Manufacturing Execution Systems coordinate and record production activities on the shop floor, including dispatching, work execution, operator instructions, equipment status, quality checks, and production genealogy. PLM supplies released product and process information to MES, while MES can return manufacturing feedback, nonconformances, and genealogy data. The boundary must be designed carefully because manufacturing process definitions may be managed jointly by PLM and MES.

PLM and SCM

Supply Chain Management coordinates sourcing, suppliers, logistics, inventory, demand, and material flows. PLM provides suppliers with appropriate product specifications, approved designs, requirements, and change information. SCM manages the flow and commercial coordination of resources; PLM manages the product knowledge that defines what is to be sourced or made.

PLM and CRM

Customer Relationship Management manages customer interactions, opportunities, sales activities, service cases, and commercial relationships. CRM may capture customer needs and complaints that influence PLM requirements or design improvements. PLM governs the technical product response, while CRM manages the relationship and commercial context.

PLM and Asset Management

Asset management focuses on physical assets after acquisition, especially their operation, maintenance, risk, performance, and total cost of ownership. PLM focuses on the product definition and its lifecycle development, though it may exchange information with asset-management systems. For example, PLM may define a pump’s approved configuration and service procedures, while asset management records the operating history and maintenance condition of a specific pump installed at a site.

The distinction is one of primary purpose, not absolute ownership of data. A mature architecture defines authoritative sources, interfaces, synchronization rules, and responsibility for each information object.

Business Value and Managerial Implications

PLM creates value through several mechanisms. It can reduce search and rework, shorten development cycles, improve change impact analysis, support regulatory evidence, increase design reuse, improve manufacturing readiness, and strengthen service knowledge. It may also enable mass customization by managing product variants and rules more systematically.

The most significant value is often risk reduction. A controlled configuration can prevent the manufacture of an outdated design. Traceability can reduce the scope of a recall. A linked requirement and test record can support certification. Accurate service information can reduce maintenance errors. These benefits may not appear as a single line item in a financial statement, but they influence cost, quality, schedule, safety, and reputation.

Managers should avoid measuring PLM only by the number of users, documents uploaded, or workflows completed. More meaningful indicators include engineering-change cycle time, percentage of parts reused, time required to locate approved information, first-pass yield, design-to-manufacturing issue rates, configuration discrepancies, warranty recurrence, and the proportion of requirements with verifiable evidence. Metrics must be interpreted in context: reducing change counts, for example, may indicate better design stability or merely discourage necessary improvements.

PLM also changes organizational behavior. It makes decisions more visible, reduces dependence on informal experts, and may challenge departmental autonomy. Leadership must therefore communicate why governance is necessary and ensure that the system supports work rather than adding administrative burden.

An Illustrative Case: PLM for a Modular Industrial Pump

Background

A fictional manufacturer, Meridian Process Systems, designs modular centrifugal pumps for chemical-processing plants. It offers several impeller sizes, motor ratings, seal arrangements, materials, and control options. The company has a CAD vault, an ERP system, a quality database, and a customer-service portal, but these systems are poorly integrated.

Situation and Problem

Engineers frequently copy old designs to meet customer delivery dates. Part numbers and descriptions are inconsistent, and the engineering BOM does not always match the manufacturing BOM. A material substitution approved for one customer is accidentally applied to another configuration. Service technicians receive manuals that do not correspond to the installed pump. When a seal failure occurs, the company takes weeks to determine which units contain the affected seal batch.

Analysis

The problem is not simply missing software. Meridian has no common product model, weak configuration rules, and unclear ownership of information. The ERP system knows purchased items and orders but cannot determine the design rationale or complete product genealogy. The customer-service portal records complaints but does not reliably connect them to product revisions. The company therefore lacks a digital thread from requirements and design through production and field service.

Approach and Strategy

Meridian establishes a PLM program with four initial priorities. First, it defines a product ontology covering assemblies, components, options, documents, materials, software, requirements, and installed units. Second, it creates controlled design, manufacturing, and service BOM views with explicit relationships. Third, it introduces a change process requiring impact analysis across engineering, procurement, manufacturing, quality, and service. Fourth, it assigns serial-number effectivity to critical components such as seals and impellers.

The PLM environment becomes authoritative for released product definitions, revisions, approved configurations, and engineering changes. ERP receives approved item and BOM information for planning and costing. MES receives released manufacturing instructions and returns production genealogy. The service portal links field cases to serial numbers and retrieves applicable manuals from the PLM repository.

A pilot is conducted on one pump family. Engineers receive training in classification, reuse, and configuration rules. A governance board reviews data standards and exceptions. The organization does not attempt to migrate every historical document immediately; instead, it prioritizes active products, safety-relevant information, and high-volume components.

Outcome

In this illustrative case, the principal outcome is improved control rather than a single software feature. Engineers can identify approved variants, manufacturing planners receive consistent structures, and service personnel can determine the applicable configuration of an installed pump. The company can narrow a potential field action by serial-number effectivity instead of examining every pump family. The pilot also reveals that some legacy part numbers have indistinguishable descriptions, leading management to sponsor a broader item-governance project.

Learning Points

The case demonstrates five lessons. PLM begins with a product-information model; integration must be based on clear responsibilities; configuration and effectivity are central to field support; implementation should be prioritized by business risk; and organizational governance is as important as technical deployment.

Implementation Challenges, Risks, and Common Mistakes

PLM programs commonly fail when organizations begin with software selection rather than a clear business problem. Another mistake is attempting to standardize every process before understanding which differences are strategically necessary. Excessive customization can make the system expensive to maintain, while excessive standardization can prevent legitimate engineering or regional requirements.

Data migration is difficult because legacy data may contain duplicates, obsolete objects, missing relationships, ambiguous ownership, and inconsistent units. Migrating poor data without cleansing simply transfers historical disorder into a new system. Equally dangerous is creating a highly controlled environment that users bypass through spreadsheets, email, or local repositories.

Other risks include weak executive sponsorship, insufficient training, unclear master-data ownership, poorly designed access rights, inadequate integration testing, and failure to involve manufacturing and service teams. PLM governance should distinguish mandatory controls from optional practices and should review whether workflows create value.

Security risks include unauthorized access to intellectual property, manipulation of released designs, leakage through suppliers, and cyberattack on cloud or integrated systems. Safety-critical industries require stronger validation, auditability, segregation of duties, and controlled release. Product data may also contain personal information, export-controlled information, or environmentally regulated substance data, requiring appropriate legal and organizational safeguards.

Ethically, engineers and managers must not conceal design limitations, suppress adverse field evidence, manipulate approval records, or release information known to be unsafe. A complete audit trail supports accountability, but it does not replace professional judgment. Automated recommendations should be reviewed by qualified personnel when decisions affect safety, compliance, or human well-being.

Digital Applications and Emerging Directions

Cloud PLM can support distributed teams, supplier collaboration, elastic computing, and faster deployment, but it raises questions about data residency, availability, integration, identity management, and contractual control. Model-based systems engineering links requirements, functions, logical architectures, physical components, verification, and validation. This approach is valuable for complex cyber-physical products in which mechanical, electrical, software, and human factors interact.

Analytics can identify recurring engineering changes, supplier quality patterns, high-risk components, and relationships between design choices and field failures. Artificial intelligence may assist with classification, semantic search, duplicate detection, requirements analysis, change-impact assessment, and retrieval of relevant lessons learned. However, AI outputs may reproduce poor historical decisions, omit context, or produce plausible but incorrect relationships. Human review, provenance, access control, and validation are essential.

Digital twins and digital threads are becoming more practical as sensor data, simulation, and enterprise information become connected. Their value depends on purpose: a predictive-maintenance twin, a production-process twin, and a design-performance twin require different data and models. Sustainability is also expanding PLM scope. Organizations increasingly need product carbon information, material passports, recycled-content data, repairability information, and evidence for circular business models. These developments reinforce the central PLM principle that lifecycle decisions require connected, trustworthy information.

Best Practices for Establishing PLM Capability

A sound PLM program generally begins by identifying high-value use cases, such as engineering change control, configuration traceability, regulatory evidence, or design-to-manufacturing synchronization. The organization should then define information ownership, lifecycle states, naming and classification rules, product structures, and interfaces with surrounding systems.

Implementation should be incremental but architecturally coherent. A pilot should involve real users, representative data, and measurable outcomes. Governance should include engineering, manufacturing, quality, supply chain, service, information technology, and business leadership. Metrics should track both adoption and business performance. Training should explain not only which buttons to press but why data quality and disciplined change matter.

Finally, PLM should be treated as a continuing capability rather than a one-time installation. Product strategies, regulations, supplier relationships, technologies, and organizational structures change. Periodic reviews are required to ensure that the product model, workflows, integrations, security controls, and performance indicators remain appropriate.

Chapter Summary

Product Lifecycle Management is an integrated business and information-management approach for governing product knowledge, processes, configurations, and decisions from opportunity through retirement. Its scope extends beyond engineering files to requirements, design, manufacturing, supply, service, field feedback, sustainability, and end-of-life activities. PDM is a foundational product-data capability within the broader PLM environment.

PLM depends on product-centric organization, controlled change, configuration integrity, traceability, cross-functional collaboration, reuse, security, and lifecycle optimization. Product structures, BOM views, revisions, effectivity, genealogy, digital thread, and digital twins are central concepts. PLM complements rather than replaces ERP, MES, SCM, CRM, and asset-management systems; each has a different primary purpose and exchanges governed information with the others.

The business value of PLM includes reduced rework and risk, faster development, improved compliance, better manufacturing readiness, stronger service support, and more informed lifecycle decisions. Achieving this value requires governance, data quality, process redesign, user participation, appropriate integration, and ethical accountability. Cloud platforms, model-based systems engineering, analytics, AI, digital twins, and sustainability requirements are extending the scope of contemporary PLM.

Key Terms

Product Lifecycle Management: An integrated approach for managing product data, processes, configurations, and decisions throughout the product lifecycle.

Product Data Management: The controlled management of product files, documents, structures, revisions, and related engineering workflows.

Product definition: The technical and functional description of a product, including its geometry, materials, performance, software, and requirements.

Product structure: The organized relationships among product assemblies, parts, documents, software, and other objects.

Bill of Materials: A structured list of components and quantities required for a product or assembly.

Configuration management: The discipline of controlling product identity, status, relationships, and approved changes.

Effectivity: The rule specifying where and when a product definition or change applies.

Revision: An identified successive state of a product-information object.

Lifecycle state: The controlled status of an object, such as preliminary, approved, released, or obsolete.

Engineering change management: The systematic evaluation, authorization, implementation, and verification of product changes.

Traceability: The ability to follow an item, decision, requirement, or material through relevant lifecycle records.

Product genealogy: The historical record of the configuration and events associated with a specific product instance.

Digital thread: A connected flow of contextual product information across lifecycle stages and systems.

Digital twin: A data-linked digital representation of a physical product, process, or system.

Single source of truth: An authoritative, governed representation of a particular information object or fact.

Engineering BOM: A BOM organized according to the product’s design structure.

Manufacturing BOM: A BOM organized to support production planning and execution.

Service BOM: A BOM organized to support maintenance, repair, and replacement activities.

Enterprise integration: The controlled exchange of information and transactions among organizational systems.

Product ontology: A formal representation of product concepts, categories, properties, and relationships.

Review Questions

Short Answer Questions

1. Define Product Lifecycle Management and identify its three central dimensions.

2. What is meant by effectivity in configuration management?

3. Distinguish an engineering BOM from a manufacturing BOM.

4. Why is PDM considered a capability within, but not equivalent to, PLM?

5. What is the purpose of a digital thread?

Long Answer Questions

1. Explain the evolution from engineering data management and PDM to contemporary PLM.

2. Discuss the major lifecycle stages of a product and explain how PLM supports feedback between them.

3. Compare PLM with ERP, MES, SCM, CRM, and asset management.

4. Analyze the principles of configuration integrity, controlled change, traceability, and product-centricity.

5. Discuss the organizational, technical, security, and ethical challenges involved in implementing PLM.

Analytical / Application Questions

1. A manufacturer discovers that service technicians are using obsolete manuals for field-installed equipment. Analyze the likely PLM weaknesses and propose an integrated corrective approach.

2. An organization wants to reduce engineering-change time by allowing all users to edit released product definitions directly. Evaluate this proposal using PLM principles.

3. Design a high-level information architecture showing how PLM should exchange information with ERP, MES, SCM, CRM, and an asset-management system for a complex industrial product.

22. Multiple Choice Questions with Answers

Question 1

Which statement best defines Product Lifecycle Management?

A. A system used only to store CAD drawings

B. An integrated approach for governing product information, processes, configurations, and decisions across the product lifecycle

C. A financial system for calculating manufacturing costs

D. A production-floor system for dispatching work orders

Correct Answer: B. An integrated approach for governing product information, processes, configurations, and decisions across the product lifecycle

Question 2

A company needs to determine which seal revision was installed in each pump shipped to a customer. Which PLM capability is most directly relevant?

A. Effectivity and product genealogy

B. Customer relationship scoring

C. Inventory valuation

D. Shop-floor labor scheduling

Correct Answer: A. Effectivity and product genealogy

Question 3

What is the principal distinction between PDM and PLM?

A. PDM manages finance, whereas PLM manages sales

B. PDM focuses on controlled product data, while PLM extends across lifecycle processes and organizational functions

C. PDM is used after product retirement, whereas PLM is used only during design

D. There is no meaningful distinction between them

Correct Answer: B. PDM focuses on controlled product data, while PLM extends across lifecycle processes and organizational functions

Question 4

Which system is primarily responsible for recording shop-floor execution, operator activities, and production genealogy?

A. CRM

B. SCM

C. MES

D. PLM

Correct Answer: C. MES

Question 5

An approved design change is made without evaluating its effects on procurement, manufacturing, quality, and service. Which PLM principle has been violated most clearly?

A. Controlled change

B. Customer segmentation

C. Financial consolidation

D. Demand forecasting

Correct Answer: A. Controlled change

Question 6

Which example best represents a digital thread?

A. A folder containing unrelated engineering documents

B. A connected chain linking requirements, design elements, manufacturing records, and field-service information

C. A spreadsheet used only for annual budgeting

D. A sensor installed without links to product records

Correct Answer: B. A connected chain linking requirements, design elements, manufacturing records, and field-service information

Question 7

A PLM system provides an approved product BOM to ERP for costing and planning. What does this illustrate?

A. Replacement of ERP by PLM

B. Integration based on different system responsibilities

C. Elimination of configuration management

D. Use of CRM for engineering control

Correct Answer: B. Integration based on different system responsibilities

Question 8

Which implementation practice is most likely to reduce the risk of transferring historical disorder into a new PLM system?

A. Migrating every file without review

B. Avoiding user participation

C. Cleansing and prioritizing legacy data before migration

D. Allowing unrestricted creation of duplicate part numbers

Correct Answer: C. Cleansing and prioritizing legacy data before migration

Question 9

Why should AI-generated change-impact recommendations in PLM be reviewed by qualified personnel?

A. AI cannot process any product information

B. AI outputs may lack context or contain plausible but incorrect relationships

C. Review prevents all future engineering changes

D. AI is intended only for financial transactions

Correct Answer: B. AI outputs may lack context or contain plausible but incorrect relationships

Question 10

Which situation most clearly demonstrates the value of lifecycle thinking?

A. Selecting a design solely because it has the lowest initial manufacturing cost

B. Evaluating a design using development, operation, maintenance, safety, and end-of-life consequences

C. Storing only the final drawing after production begins

D. Separating service data permanently from engineering data

Correct Answer: B. Evaluating a design using development, operation, maintenance, safety, and end-of-life consequences