What is Configuration Management in PLM?

What is Configuration Management in PLM?

Configuration management is the discipline that keeps a product's definition trustworthy over time. Not the drawing set. The definition: what has been approved, what has changed since, who authorized the change, and what was actually built and shipped against it.

That last part is where most people's mental model stops short. Configuration management (CM) is not about the product family and its options. It is about any one configuration and its history. Four questions, asked of any product at any moment:

1. What is the approved definition right now?
2. Which changes to that definition were authorized, by whom, and effective from when?
3. What did we actually build and ship?
4. Where do the units in the field diverge from the definition?

A PLM system can store the answers. Only a CM discipline produces them. I spent enough years watching implementations confuse the two that I wrote a separate piece on the five configuration management myths that sink PLM programs. This page is the constructive version: what CM is, how it works, and how to tell whether you have it.

The four mechanics

CM has been formalized for decades, first by the US military and now by ISO 10007 and the EIA-649 standard, and the mechanics have barely changed. Four of them.

Configuration identification. Decide what is under control (parts, assemblies, software builds, documents) and establish a baseline at each lifecycle gate: a functional baseline when requirements are approved, an allocated baseline at design release, a product baseline at manufacturing release. A baseline is a frozen, approved state. Everything after it is a delta.

Change control. Every change to a baseline goes through an engineering change order: problem, proposed solution, impact analysis across every affected part and configuration, approval, effectivity, implementation, closure. The engineering change management article walks the four stages. The point for CM is simple: if a change did not go through this, the definition and the product have silently diverged.

Status accounting. Someone has to be able to say, at any time, what the current state of every configuration is: which changes are approved but not yet implemented, which are effective from which serial number, which baseline a given unit was built to. This is the part organizations most often skip because it feels like bookkeeping. It is the part that makes the other three usable.

Configuration audits. Periodically verify that what was built matches what was approved (physical configuration audit) and that the approved definition meets its requirements (functional configuration audit). An audit that always passes is not an audit.

As-designed, as-built, as-maintained

The reason CM matters outside the drawing office is that products leave it. Three records describe the same unit at different points in its life.

The as-designed record is the approved definition in PLM. The as-built record is what actually went into serial number 4471 on the day it was assembled: which part revisions, which supplier lots, which software build. It originates in MES, not PLM. The as-maintained record adds every field modification and service event afterwards. Together they are the unit's product genealogy.

CM's job is to keep those three linked so that divergence is visible rather than discovered. When a bearing supplier's lot turns out to be out of tolerance, an organization with linked as-built records queries every unit that consumed that lot and issues a targeted service bulletin the same afternoon. An organization without them recalls the production year. The 737 MAX is the case study everyone cites for what happens when a safety-relevant change is not traced through this chain, and it belongs on this page too.

What configuration management is not

Three confusions come up in almost every PLM engagement.

It is not documentation. Documents are CM's output. Control is its purpose. An organization that treats CM as paperwork for auditors produces paperwork. It does not produce the ability to identify affected units by serial number in hours.

It is not variant management. Variant management handles the product family dimension: the 47 option combinations, the configurable BOM that represents them, the compatibility rules between options. Configuration management handles the lifecycle dimension of any one of those 47 as it evolves. You can have sophisticated variant management and still be unable to say what was in the unit that failed. Both disciplines are necessary. The older version of this very page defined CM as "tracking product variants", which is exactly the confusion I am warning about.

It does not live in one system. PLM is authoritative for the product structure, the engineering definition and the change record. MES owns as-built actuals. ERP owns procurement and cost. QMS owns nonconformances and corrective actions. CM is the governance layer that says which system is authoritative for which data and how the records stay linked across the seams. "PLM as the single source of truth" is a slogan, not an architecture, and the PLM data governance article explains the multi-system authority model that actually works.

Where CM meets the BOM

Configuration management and the bill of materials are inseparable, because the BOM is the primary thing under configuration control. Three points where they meet:

• The engineering BOM is the as-designed structure. Its release establishes the product baseline.
• The manufacturing BOM is derived from it through process planning, and its release to MES is the handoff at which as-built capture begins. The EBOM vs MBOM article covers why the two are different documents, not different views.
• Effectivity on the BOM, by date or by serial number, is how an ECO's scope is expressed in data. Effectivity is the bridge between "we approved a change" and "these specific units carry it". The effectivity explainer goes deeper.

What good looks like

Strip away the standards vocabulary and mature CM has five observable properties:

1. Every change has a sponsoring change request with documented scope and impact analysis before it is implemented, not after.
2. Every baseline is formally established before the lifecycle gate that depends on it.
3. As-built records are captured at the point of manufacture, linked to the as-designed record, and divergence is tracked as a first-class data element rather than a spreadsheet.
4. Configuration audits are scheduled, resourced and occasionally fail.
5. The process is enforced at system gates. You cannot release to manufacturing without the CM records in place.

When CM does not work, the failure is almost never the tool. It is one of the confusions above: CM treated as documentation, applied only where a customer contract demands it, expected to live entirely in PLM, confused with variant management, or waiting for a software upgrade to fix what is a governance problem. A new PLM system carrying the same governance gaps produces the same failures on a larger invoice.

Related Concepts

• 5 Configuration Management Myths That Undermine PLM Implementations, the long-form argument behind this page
• Engineering Change Management in PLM, the four-stage change process that CM depends on
• What is Revision Control?, the version control foundation underneath CM
• What is Product Genealogy?, the as-built and as-maintained record of a specific unit
• What is Effectivity in PLM?, how change scope is expressed on the BOM
• PLM vs PDM, where CM sits in the boundary between the two
• Configuration Management, Configuration Baseline and Engineering Change Order in the glossary

Frequently Asked Questions

What is the difference between configuration management and variant management?

Variant management addresses the product family dimension: how many option combinations exist, how a configurable BOM represents them, and which options are compatible. Configuration management addresses the lifecycle dimension: how any one specific configuration evolves over time, which changes were authorized, what the baseline was at each gate, and where the as-built unit diverges from the as-designed record. A company can have excellent variant management and still be unable to say which configuration was in the unit that failed in the field. Both are needed and neither replaces the other.

What is a configuration baseline?

A baseline is the formally approved product definition at a defined lifecycle gate, frozen so that subsequent changes can be measured against it. Typical baselines are the functional baseline at requirements approval, the allocated baseline at design release, and the product baseline at manufacturing release. Every engineering change after a baseline is a controlled delta from it, which is what makes the change history auditable.

How does an engineering change order fit into configuration management?

The engineering change order is the mechanism by which a baseline is allowed to change. It records the problem, the proposed solution, the impact analysis across affected parts and configurations, the approvals, the effectivity (which serial numbers or dates the change applies to), and the closure. Without an ECO process, changes still happen; they just happen without a record, which is how as-built units quietly stop matching the drawings.

What is the difference between as-designed, as-built and as-maintained?

As-designed is the approved engineering definition in PLM. As-built is the record of what was actually assembled into a specific unit at the point of manufacture, including which revisions and which supplier lots. As-maintained adds every service event and field modification after delivery. Configuration management links all three so that divergence is visible, which is what recall scoping, warranty adjudication and certification depend on.

Does configuration management live in the PLM system?

Partly. PLM is authoritative for the approved product structure, the engineering definition and the change record. MES is authoritative for as-built data, ERP for procurement and cost, QMS for nonconformances and corrective actions. Configuration management is the governance layer that defines which system owns which data and how those records stay linked. Expecting PLM alone to be the single source of truth is one of the most common ways CM programs fail.

Which industries need configuration management?

Any industry whose products have variants, undergo engineering changes or carry safety or regulatory obligations, which is nearly all of them. Aerospace and defense formalized the discipline first and still apply it most rigorously. Medical devices need it for design history files, automotive for recall scope and over-the-air update targeting, industrial equipment for servicing machines that have been in the field for a decade. The rigor scales with the product; the need does not go away.