A working guide to Product Lifecycle Management

What PLM is for

Product Lifecycle Management is the discipline of knowing what your product is, who changed it, why, and what else that change affected. Everything a PLM system does is downstream of those four questions.

The category name is unhelpful because it suggests scope — cradle to grave, concept to retirement — when the useful definition is narrower. A PLM is the system of record for product definition and the process by which it changes. Not manufacturing execution, not planning, not accounting.

The reason a separate system exists at all is temporal. An ERP item must exist before it can be transacted, so an ERP has nothing to say about the eight months before that: the concepts, the alternatives evaluated and rejected, the revisions that never released, the supplier that failed qualification, the requirement that drove a tolerance. That is most of what an engineering organisation argues about, and none of it is item-shaped.

The five things it actually does

Vendor feature lists run to two hundred rows. Underneath, there are five jobs, and a tool that does these well is a good PLM regardless of what else it has.

• Hold the definition. Parts, structures, documents, specifications and their relationships — with revisions that mean something and identity that never changes.
• Control the change. A record of what was proposed, what it affected, who agreed, and when it took effect. This is the part that cannot be bolted on later, because the history it produces is the value.
• Answer questions about configuration. What is in this product, as at this date, for this unit, at this plant, with these options. Most tools store the data to answer this and leave the answering to a person.
• Connect the graph. A requirement verified by a test, satisfied by a part, sourced from a supplier, described by a drawing, touched by an open change. The questions worth automating are traversals of that graph.
• Publish outward. The released structure has to reach the ERP that plans it and the plant that builds it, dated, in a shape they can act on.

When a company actually needs one

Not at a headcount. The honest triggers are specific, and a company with none of them is usually better served by the BOM module in the ERP it already pays for.

A second plant. The moment the same product is built in two places, a single global structure starts being corrected by hand on one of the floors, and those corrections never travel back.

A serialised product with field service. Once somebody can ask what unit 1420 contained fourteen months ago, reconstruction from work orders stops being good enough — it tells you what was consumed, not what was specified.

A change that must take effect on a future date. If approval and effect are the same event, every phased cutover is a manual reconciliation and stock gets stranded.

A contractual need to prove configuration. A customer qualification, a regulated market, an acquirer's diligence. All three ask the same question: show me what you shipped and the evidence behind it.

A duplicate part problem. Three internal numbers for one screw means three approved manufacturer lists, three qualifications, and three chances to miss an end-of-life notice.

The vocabulary that matters

Six terms carry most of the weight, and confusion about them causes most of the bad decisions.

Revision versus iteration versus version. A revision is a released state others reference. An iteration is work in progress, private to a workspace. A version is what a specific unit shipped with. Tools that collapse these into one field make engineering history unrecoverable, and it cannot be reconstructed later.

Effectivity. The condition under which a BOM line applies — a date range, a unit-number range, a plant. Not the same as a lifecycle state, and not the same as a revision.

EBOM and MBOM. What the product is, versus how a plant builds it. They diverge legitimately and both are correct.

AML and AVL. The approved manufacturer list is which manufacturer parts engineering qualified for an internal part. The approved vendor list is who you buy from. They answer different questions and one supplier field has never handled both.

Deviation and waiver. A deviation permits shipping off-specification within bounds; a waiver accepts one non-conformance after the fact. Neither changes the design, which is why modelling them as a change order with a flag makes the design history unreadable.

How to evaluate one

Feature comparison converges — every vendor manages BOMs, changes, documents and suppliers. Five questions separate them, and none appear on a feature grid.

Ask what happens when two BOM lines disagree about which is effective today. A tool with a resolution engine returns one answer and shows why the other was dropped. A tool without one returns both and expects the reader to know.

Ask for the system-of-record matrix. Object by object: which system masters the field, which direction it moves, what triggers it, what happens on conflict. Every vendor says they integrate with your ERP; the ones who can produce this table have thought about it.

Ask what happens when the configuration model turns out to be wrong. A sandbox with a diff and a rollback is a different product from a vendor ticket and a migration window.

Ask to paste four hundred rows into the BOM grid. Adoption is decided in the first hour, and a tool that makes bulk editing painful will be routed around by exactly the senior engineer whose judgement you were buying it for.

Ask what it will not do. A vendor who cannot name their boundaries has either not found them or will not tell you, and you will find them during implementation.

What PLM is not

Not an ERP. No general ledger, no purchasing, no inventory movements, no work orders. A PLM that grows those becomes a worse ERP than the one you have.

Not an MES. Recording that an operator measured a characteristic at a station on a specific unit is execution data, generated where the work happens.

Not a CAD system. Geometry belongs where it is authored and versioned. A PLM that copies CAD files in creates two sources of truth for the same shape.

Not a document repository. Documents are in it, with revisions and controlled distribution, but a tool whose main artefact is a stored PDF has automated the filing rather than the work.