6. Product Data, Configuration and Engineering Change Management

Introduction and Context

Product lifecycle management (PLM) depends on the ability to know exactly what a product is, which information defines it, which version is authorized, and what has changed over time. In a simple product, this may appear to be an administrative concern. In a complex engineered product—such as an aircraft, medical device, industrial machine, automobile, or power system—it is a central technical and managerial discipline. A product is represented by thousands of drawings, models, specifications, bills of material, software objects, test results, supplier documents, service instructions, and compliance records. These objects are interdependent. A change to one may affect many others.

Product data management, product configuration management, and engineering change management provide the controls needed to maintain product integrity throughout the lifecycle. They ensure that design intent is preserved, manufacturing receives the correct definition, service personnel work with approved information, and historical decisions remain traceable. The subject therefore connects engineering design with manufacturing, procurement, quality, regulatory compliance, maintenance, and business governance.

The central question is not merely whether an organization stores data. It is whether the organization can establish an authoritative, controlled, and auditable product definition at any point in time. This chapter examines the concepts, processes, systems, and managerial decisions required to achieve that objective.

Learning Objectives

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

1. Explain the role of product data and configuration management in PLM.

2. Distinguish documents, metadata, versions, revisions, baselines, and configurations.

3. Describe configuration identification, control, status accounting, and verification.

4. Design an engineering change request, change order, review, approval, and implementation workflow.

5. Analyse effectivity, options, variants, and traceability in complex products.

6. Evaluate risks, governance requirements, and common failures in change management.

7. Identify how PLM platforms, digital threads, analytics, and AI can support controlled product information.

8. Apply these principles to an industrial engineering case.

Product Data as the Authoritative Description of a Product

Product data includes every structured or unstructured information object used to define, develop, manufacture, operate, maintain, and retire a product. Typical objects include requirements, CAD models, drawings, specifications, calculations, analysis reports, bills of material (BOMs), software versions, inspection plans, supplier records, manufacturing instructions, service manuals, and non-conformance reports.

The value of product data lies not only in its content but also in its context. A drawing without a revision status, owner, approval record, or relationship to a part is incomplete from a lifecycle perspective. Consequently, a PLM system normally stores both the data object and its metadata. Metadata may include part number, title, revision, maturity state, author, responsible organization, security classification, effective date, linked requirement, and relationships to other objects.

An authoritative product record has four characteristics. It is identifiable, meaning that it has a unique and stable identity. It is controlled, meaning that authorized processes govern modification. It is relational, meaning that connections to requirements, components, processes, and evidence are visible. It is historical, meaning that prior states and decisions can be reconstructed.

Important terminology

A data object is a managed item such as a drawing, CAD file, specification, or BOM. A document is an information package intended for human interpretation, whereas a model may be a digital representation used directly by engineering or manufacturing software. Metadata describes an object and its management status. A part number identifies a product item or component; it should not be confused with a revision, which identifies a controlled state of that item.

A version is commonly an iteration of an object during development. A revision is an officially identified change to an approved or released object. Organizations use these terms differently, so the governing data model must define them explicitly. A lifecycle state or maturity state indicates where an object is in its process—for example, In Work, Under Review, Released, Obsolete, or Superseded. A lifecycle state is not the same as a revision: a revision may move through several states.

A check-in/check-out mechanism controls concurrent editing. It prevents unauthorized overwriting and records who worked on an object. Access control may be role-based, project-based, attribute-based, or a combination of these. The objective is to provide people with the information they need while protecting intellectual property and preventing uncontrolled alteration.

Configuration Management: Controlling the Product Definition

Configuration management (CM) is the disciplined process of establishing and maintaining consistency between a product’s functional, physical, and performance characteristics and its recorded definition throughout the lifecycle. It is particularly important where products are customized, safety-critical, regulated, or manufactured in long production runs.

A useful framework consists of four mutually reinforcing functions:

• Configuration identification: defining the items, characteristics, naming rules, and documentation that constitute the product.
• Configuration control: evaluating, authorizing, and implementing changes.
• Configuration status accounting: recording the identity, status, and history of configuration items and changes.
• Configuration verification and audit: confirming that the physical product and its records conform to the approved definition.

Configuration identification

The first decision is what should be controlled as a configuration item. A configuration item may be a complete product, subsystem, software package, purchased component, interface, or document whose performance or interchangeability must be controlled. If the item is too large, detailed changes become difficult to isolate; if it is too small, the system becomes overloaded with administrative transactions. The appropriate level depends on risk, interfaces, independent release needs, and the consequences of change.

Configuration identification also establishes a product structure. A product structure may contain assemblies, components, materials, software, documents, and allocated requirements. It should represent both the engineering view and, where necessary, manufacturing or service views. A single product may therefore have an engineering BOM, manufacturing BOM, service BOM, and software configuration, linked but not necessarily identical.

Baselines

A baseline is a formally established set of configuration information that serves as a reference for further activity. Examples include a requirements baseline, functional baseline, preliminary design baseline, product baseline, and as-built baseline. A baseline is not simply a backup copy. It is an agreed configuration against which changes, verification, and performance can be assessed.

Baselines are valuable at decision gates. Once a design baseline is approved, further modifications should be processed through change control rather than informal editing. In a production environment, the as-designed baseline may differ from the as-built configuration because approved deviations, substitutions, or serial-number-specific changes may have occurred. The as-maintained configuration may differ again after field repairs. Effective PLM distinguishes these views and records their relationships.

Effectivity and configuration logic

Effectivity specifies where and when a configuration applies. It may be based on serial number, lot, date, production sequence, customer, plant, geographic region, software release, or a combination of these. For example, a modified bracket may be effective for serial numbers 1201 and above, while a software patch may apply only to vehicles with a particular control unit.

Options and variants introduce configuration logic. A product may contain optional engines, regional electrical systems, customer-selected features, or mutually exclusive components. Rules such as “if option X is selected, component Y is required” prevent invalid configurations. Configuration management must therefore connect the product structure with constraints, effectivity, and approved alternatives. Without this logic, a system may show a technically impossible or commercially incorrect product.

Engineering Change Management as a Decision Process

Engineering change management (ECM) governs the proposal, assessment, approval, implementation, and closure of changes to product definition. It should be treated as a decision process rather than a document-routing exercise. A good process makes the reason for change visible, evaluates consequences systematically, assigns accountability, and preserves evidence.

The change lifecycle

A typical workflow begins with an Engineering Change Request (ECR) or equivalent proposal. The request identifies the problem, source, affected product, urgency, preliminary justification, and known risks. Sources may include test failure, customer feedback, supplier discontinuation, regulatory action, cost reduction, manufacturability improvement, field failure, or safety analysis.

The request is then screened for completeness and classified. Classification may distinguish emergency, major, minor, corrective, preventive, cost-reduction, obsolescence, and regulatory changes. Classification should influence review depth, not provide a means of avoiding review.

A cross-functional impact analysis follows. Engineering examines performance, interfaces, reliability, safety, and verification. Manufacturing examines tooling, process capability, inventory, work instructions, and production disruption. Procurement examines suppliers, lead times, contracts, and qualification. Quality and regulatory specialists assess compliance and validation. Service teams examine installed products, spare parts, manuals, and maintenance procedures. Finance may evaluate cost, warranty exposure, and business benefit.

If the change is feasible, an Engineering Change Order (ECO) or change notice is prepared. It defines the authorized modification, affected configuration items, new revisions, effectivity, implementation actions, verification requirements, and responsible owners. A change control board (CCB), design authority, or delegated approver reviews the proposal according to its significance.

After approval, the change is implemented in the controlled system. Related CAD files, drawings, specifications, BOMs, software, process plans, and documents are revised in a coordinated manner. Verification and validation evidence is attached. The change is then released for its intended effectivity, communicated to affected functions, and monitored until closure.

Approval and segregation of duties

Approval must reflect technical competence and organizational accountability. The person who creates a change should not be the sole person who approves it, especially when safety, compliance, or commercial commitments are involved. Segregation of duties reduces the risk of unreviewed changes and supports auditability. Digital signatures should identify the signer, role, date and time, meaning of approval, and the exact information approved.

Not every change requires the same authority. A minor typographical correction in a nontechnical document may follow a delegated route, while a change to a pressure boundary, safety function, or certified software may require formal design authority, customer, or regulator involvement. The workflow should be risk-based and defined in advance.

Emergency changes

Emergency changes are sometimes necessary to address an immediate safety threat, production stoppage, or field failure. Emergency status should accelerate review, not eliminate it. The minimum emergency process should identify the responsible authority, record the rationale, define temporary controls, specify affected units, and require retrospective documentation and verification. Organizations that permit informal emergency work without later reconciliation create configuration uncertainty and audit exposure.

Traceability, Status Accounting, and Auditability

Traceability is the ability to follow relationships and decisions across the product lifecycle. A robust traceability chain may connect a customer or regulatory requirement to a system requirement, design feature, component, test result, release record, manufacturing operation, and service event. It supports impact analysis and demonstrates that obligations have been addressed.

Configuration status accounting provides the current and historical status of configuration items. At minimum, it should answer: What is the approved revision? When did it become effective? Which changes produced it? Which products or serial numbers contain it? Which verification evidence supports it? What superseded it? Who approved the decision?

Auditability requires more than an activity log. An audit trail should preserve the before-and-after state, actor, timestamp, reason, approval, affected objects, and implementation evidence. Records must be protected against unauthorized alteration and retained according to contractual, regulatory, and organizational requirements. A system that records only the latest file cannot reconstruct product history and therefore provides weak control.

Two audits are especially useful. A functional configuration audit examines whether the configuration satisfies its specified functional and performance requirements. A physical configuration audit examines whether the actual product and its associated records match the approved physical definition. Inspection reports, as-built records, software hashes, serial-number histories, and non-conformance dispositions may provide evidence.

An Integrated PLM Workflow

A mature PLM environment links product structures, requirements, CAD, simulation, manufacturing planning, quality, supplier data, and service information. The workflow can be understood as a controlled loop:

1. Identify the need or problem.

2. Record and classify the proposed change.

3. Establish the affected configuration and effectivity.

4. Analyse technical, operational, commercial, and compliance impact.

5. Decide whether to approve, reject, defer, or request more information.

6. Prepare and verify the changed definition.

7. Release the change through controlled states.

8. Implement it in production, supply, software, and service channels.

9. Confirm effectiveness and close the change.

10. Preserve the complete history for future analysis.

This loop should be supported by a common product data model. If engineering, manufacturing, and service systems maintain disconnected identities and revision rules, synchronization errors are likely. Integration does not necessarily require a single application, but it requires governed interfaces, common identifiers, clear ownership, and reliable status exchange.

Practical Applications in Mechanical Engineering

In mechanical design, configuration control prevents a released drawing from being silently replaced by an unapproved CAD file. In manufacturing, it ensures that the work instruction, tool definition, inspection plan, and BOM correspond to the same product revision. In procurement, it identifies which supplier part revision is qualified and whether an alternative is approved. In maintenance, it determines whether a service bulletin applies to a particular serial number.

For systems engineering, traceability links allocated requirements to design outputs and verification evidence. For quality engineering, change history supports root-cause analysis and corrective action. For project management, configuration baselines provide a stable reference for scope, cost, and schedule. For leadership, change data reveals recurring design weaknesses, approval bottlenecks, and the cost of late changes.

A useful performance dashboard may include average change-cycle time, percentage of changes returned for incomplete analysis, overdue approvals, number of products affected by a change, post-release defects, unauthorized-access incidents, and the proportion of released objects with complete relationships. Metrics should not reward rapid approval at the expense of sound analysis.

Illustrative Case: Configuration Control in a Modular Pump Product Line

Background

The following is an illustrative case based on a common industrial situation. A manufacturer produces centrifugal pumps in several sizes for chemical-processing customers. The product family shares a common housing and shaft architecture but includes different impellers, seals, motors, materials, and control packages.

Situation and problem

A seal supplier announces that an elastomer is being discontinued. Procurement proposes an alternative seal that appears dimensionally interchangeable. Engineering approves the substitute in an email and manufacturing begins using it for selected orders. However, the PLM system still shows the original seal in the engineering BOM, while purchasing and the service manual contain different part references. Two customers later experience leakage because their process temperature exceeds the qualified range of the substitute.

Analysis

The failure was not simply a supplier-selection error. Configuration identification was incomplete: the seal material and temperature rating were not adequately represented as controlled attributes. Effectivity was unclear, so the organization could not immediately determine which serial numbers received the substitute. The change also bypassed formal impact analysis, including validation, customer notification, and service documentation. Email approval created weak evidence and no reliable linkage between the decision and affected product objects.

Approach and solution

The company first established a configuration item for the seal assembly and defined critical characteristics: material, dimensions, pressure rating, temperature range, compatibility, supplier, and qualification status. A formal ECR identified the obsolescence issue. The cross-functional analysis included design engineering, materials engineering, quality, procurement, manufacturing, service, and regulatory representatives.

Testing compared the proposed seal under pressure, temperature, chemical compatibility, and endurance conditions. The change order then revised the seal part number and related drawings, BOMs, specifications, inspection criteria, supplier qualification record, service manual, and customer configuration rules. The substitute was made effective only for specified pump variants and serial numbers after validation. Existing inventory was segregated, and field units were identified using serial-number traceability. A service bulletin defined inspection and replacement requirements.

Outcome

The organization gained a single authoritative record of the approved seal and could distinguish affected configurations. The change took longer than the informal substitution would have taken, but it prevented further field uncertainty and established evidence for customer and quality review. The company also discovered that its configuration model needed explicit control of material and performance attributes, not merely geometric interchangeability.

Learning points

The case demonstrates that a change may be technically small but systemically significant. A part cannot be considered interchangeable solely because it fits. Configuration logic must include performance, environment, qualification, effectivity, and documentation. It also shows why the change process must reach procurement, manufacturing, service, and customers rather than ending with engineering approval.

Challenges, Risks, and Common Mistakes

A frequent mistake is treating PLM as a file repository. Storage without relationships, status, and governance does not create configuration control. Another is confusing revision with lifecycle state, causing teams to interpret “released” inconsistently. Duplicate part numbers, uncontrolled spreadsheets, local naming conventions, and email approvals create parallel product definitions.

Overly complex workflows can be as damaging as weak workflows. If every typographical correction requires a major board review, personnel will seek informal workarounds. If workflows are too permissive, safety-critical changes may pass without adequate evidence. The solution is a clearly documented, risk-based process with delegated authority and defined escalation.

Other risks include incomplete impact analysis, failure to account for work-in-process inventory, poor serial-number traceability, unlinked supplier changes, inadequate cybersecurity, and loss of data during system migration. Data migration deserves particular attention: importing files without preserving revisions, relationships, approvals, and effectivity can create a false appearance of control.

Human factors also matter. Engineers may resist administrative work when the system is slow or poorly designed. Managers may measure closure speed rather than quality. Training should explain the engineering purpose of configuration management, not merely the buttons to click. Product data ownership, stewardship, and accountability should be assigned explicitly.

Governance, Ethics, and Regulatory Considerations

Configuration decisions can affect safety, public welfare, environmental performance, and contractual compliance. Suppressing an adverse test result, backdating an approval, or releasing a change without communicating its effectivity is professionally unacceptable. Engineers and managers have a duty to preserve truthful records and escalate risks.

Regulated industries may require design history files, device master records, aviation configuration records, nuclear quality records, or other controlled evidence. The exact requirements vary by sector and jurisdiction, but common principles include controlled approvals, retention, access restriction, record integrity, and demonstrable traceability.

Cybersecurity is part of configuration governance. Access should follow least privilege; privileged actions should be logged; sensitive design data should be protected in transit and at rest; and suppliers should be managed through controlled collaboration mechanisms. Digital signatures and immutable audit mechanisms can strengthen evidence, but technology does not replace clear responsibility or competent review.

Digital PLM, Analytics, and AI

Modern PLM platforms can provide workflow orchestration, visual product structures, revision comparison, effectivity management, electronic signatures, and integrations with ERP, manufacturing execution, requirements, and service systems. Model-based definition allows 3D product information and manufacturing annotations to become controlled product data rather than merely attachments to drawings.

Analytics can identify frequently changed components, long approval queues, recurring non-conformances, and suppliers associated with repeated changes. A change-impact graph can help reviewers discover linked requirements, assemblies, tests, and field units that may otherwise be missed.

AI may assist by classifying change requests, extracting affected part numbers from text, detecting inconsistent metadata, recommending reviewers, comparing revisions, and identifying probable downstream impacts. These applications require human oversight. AI-generated recommendations may be incomplete, biased by historical data, or unable to understand safety significance. The approval decision and professional accountability must remain with authorized personnel. AI outputs used in a regulated process should themselves be controlled and reproducible.

Current Developments and Best Practices

Important developments include digital thread architectures, model-based systems engineering, cloud PLM, supplier collaboration portals, digital twins, and increased integration of software with mechanical product definitions. Products increasingly combine mechanical, electrical, electronic, and software elements; configuration management must therefore control cross-domain dependencies and release compatibility.

Effective practice generally includes:

• one controlled identity for each configuration item;
• explicit separation of part identity, revision, lifecycle state, and effectivity;
• risk-based change classification and approval authority;
• cross-functional impact analysis;
• linked requirements, design outputs, tests, and field records;
• controlled as-designed, as-built, and as-maintained configurations;
• complete electronic audit trails and protected records;
• defined rules for emergency changes and retrospective reconciliation;
• regular configuration audits and data-quality reviews; and
• metrics that assess quality, risk, and effectiveness rather than speed alone.

The most important principle is that configuration management should be designed around engineering decisions and product risk. A system is successful when people can confidently answer what was intended, what was built, what was changed, why it changed, who authorized it, and which products are affected.

Chapter Summary

Product data management provides the controlled information foundation of PLM. Configuration management identifies the product items and establishes their approved definitions through identification, control, status accounting, and verification. Baselines provide stable references, while effectivity and configuration logic determine where and when a design applies.

Engineering change management converts a recognized need into a reviewed, authorized, implemented, and traceable change. Its effectiveness depends on impact analysis, cross-functional participation, segregation of duties, controlled release, and evidence of verification. Traceability connects requirements, designs, manufacturing records, service actions, and field configurations. PLM platforms, analytics, model-based definition, and AI can improve this work, but governance, professional judgment, and record integrity remain essential.

Key Terms

Product data: Information used to define, develop, produce, operate, maintain, or retire a product.

Metadata: Descriptive information that identifies and governs a data object.

Configuration item: A product element placed under formal configuration control.

Configuration management: The discipline of maintaining consistency between a product and its approved recorded definition.

Configuration identification: Definition of controlled items, characteristics, names, and structures.

Configuration control: Evaluation, authorization, and implementation of product changes.

Status accounting: Recording the identity, status, history, and relationships of configuration items.

Configuration audit: Examination of conformity between approved records and functional or physical product reality.

Baseline: An approved configuration used as a reference for subsequent work and change.

Version: An iteration of a data object, commonly during development.

Revision: An officially identified state resulting from a controlled change.

Lifecycle state: A maturity or process status such as In Work, Released, or Obsolete.

Effectivity: The condition defining where, when, or to which units a configuration applies.

Product structure: The organized relationship among assemblies, parts, software, documents, and requirements.

Engineering Change Request: A formal proposal describing a problem or need for change.

Engineering Change Order: An authorized instruction defining and controlling implementation of a change.

Change control board: A body or authority that evaluates and approves changes.

Traceability: The ability to follow information, relationships, decisions, and evidence through the lifecycle.

As-built configuration: The actual recorded configuration incorporated into a particular produced unit.

Digital thread: Connected lifecycle information and relationships linking product data across systems and stages.

Review Questions

Short Answer Questions

1. What distinguishes a revision from a lifecycle state?

2. Why is a baseline more than a backup copy?

3. Define effectivity and give two possible bases for it.

4. What are the four principal functions of configuration management?

5. Why should an engineering change include service and manufacturing impact analysis?

Long Answer Questions

1. Explain how configuration identification, control, status accounting, and audit work together throughout the product lifecycle.

2. Describe a complete engineering change workflow from initial request to closure, including the role of verification.

3. Discuss the differences among as-designed, as-built, and as-maintained configurations.

4. Explain how product structures, options, variants, and effectivity support complex product governance.

5. Evaluate the organizational and technical consequences of relying on email and uncontrolled spreadsheets for engineering changes.

Analytical / Application Questions

1. A manufacturer discovers that a supplier has changed the material of a qualified component without changing its part number. Design an appropriate configuration and change-control response.

2. A software update is compatible with some but not all versions of a machine’s control hardware. Propose an effectivity and traceability model for releasing the update.

3. A company has short change-cycle times but frequent field failures after release. Identify likely weaknesses in its process and recommend performance measures and controls.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a baseline from an ordinary data backup?

A. A baseline is always the newest available file

B. A baseline is a formally approved reference configuration

C. A baseline contains only manufacturing information

D. A baseline cannot be changed under any circumstance

Correct Answer: B. A baseline is a formally approved reference configuration

Question 2

A seal fits mechanically but has not been qualified for the product’s temperature range. What is the most appropriate conclusion?

A. It is automatically interchangeable

B. It can be used if procurement approves it

C. Interchangeability has not been established because performance characteristics matter

D. It requires only a new document title

Correct Answer: C. Interchangeability has not been established because performance characteristics matter

Question 3

Which activity primarily belongs to configuration status accounting?

A. Designing a new component

B. Recording the approved revision and its effective serial numbers

C. Selecting a manufacturing supplier

D. Performing a fatigue calculation

Correct Answer: B. Recording the approved revision and its effective serial numbers

Question 4

What is the main purpose of effectivity control?

A. To determine the file size of a CAD model

B. To identify where and when a configuration applies

C. To replace all product options with one standard design

D. To eliminate the need for validation

Correct Answer: B. To identify where and when a configuration applies

Question 5

An engineering change modifies a pressure boundary. Which approach is most appropriate?

A. Use an informal email approval because the change is local

B. Allow the designer to approve it alone

C. Apply risk-based cross-functional review and formal verification

D. Implement it first and document it only if a failure occurs

Correct Answer: C. Apply risk-based cross-functional review and formal verification

Question 6

Which record most directly represents the actual configuration incorporated into a particular manufactured unit?

A. As-designed configuration

B. As-built configuration

C. Preliminary requirements baseline

D. Rejected change request

Correct Answer: B. As-built configuration

Question 7

Why is segregation of duties valuable in engineering change approval?

A. It prevents any engineer from editing data

B. It reduces the possibility that a change is approved without independent review

C. It eliminates the need for technical expertise

D. It ensures every change has four approvers

Correct Answer: B. It reduces the possibility that a change is approved without independent review

Question 8

A change-control dashboard shows very short approval times but many post-release defects. What is the most reasonable interpretation?

A. The process is necessarily efficient

B. Approval speed may be rewarded at the expense of impact analysis and verification

C. The product structure is certainly correct

D. Post-release defects are unrelated to change management

Correct Answer: B. Approval speed may be rewarded at the expense of impact analysis and verification

Question 9

Which capability is most useful for discovering that a revised component affects an inspection plan and service manual?

A. A disconnected file repository

B. A product data model with linked relationships

C. A larger email distribution list

D. A reduction in metadata fields

Correct Answer: B. A product data model with linked relationships

Question 10

What is the appropriate role of AI in a regulated engineering change process?

A. AI should make the final approval decision without human review

B. AI can assist with classification and impact discovery, while authorized personnel retain accountability

C. AI should replace configuration audits

D. AI outputs do not need to be recorded

Correct Answer: B. AI can assist with classification and impact discovery, while authorized personnel retain accountability