PLM for Engineering Data: Drawing Revisions, ECR/ECO and BOM

Why PLM for engineering data is needed

When engineering data live in folders, email and spreadsheets, confusion quickly appears. One department works from a new drawing revision, another prints an old one, and the assembly shop encounters the "wrong" part. Deadlines, quality and people suffer.

PLM for engineering data is a central place to store and manage everything that describes a product. This includes drawings, specifications, requirements, test reports, CAD files and related documents. More importantly, PLM stores context: which revision is current, what is approved, and what is still in progress.

What goes wrong without a single source of truth

Without a single source of truth, errors become systemic. Procurement orders by an outdated specification, production assembles by an old instruction, and quality inspects against another edition. Even with best intentions, manual synchronization doesn't scale.

Typical symptoms: designers, manufacturing engineers and production use different drawing revisions; changes reach procurement late or unclearly; errors and rework appear on the shop floor; people waste time arguing "which specification is correct"; the history of decisions and reasons for changes is lost.

Who is involved

PLM links teams that used to operate in different "worlds": designers release drawings and changes, manufacturing engineers prepare routings and tooling, production assembles from approved documentation, procurement orders components, and quality inspects against current requirements.

Simple example: a connector on a board is changed because the supplier is out of stock. If the change isn't recorded centrally, procurement may buy the old connector and the shop will find a mismatch during assembly. In PLM the change follows a clear path and becomes visible to everyone immediately, with date, status and applicability.

Basic data model: what should live in PLM

For PLM to work for engineering data, you must agree on simple objects and their relationships. Otherwise the system becomes a file vault where nobody knows what is current, what is obsolete and what can be released to production.

At the core are two "worlds": the product (what we make) and the documentation (how it is described and validated). The product includes parts, assemblies and variants. Documentation includes drawings, specifications, 3D models, technical conditions, instructions and test reports. Changes (requests and decisions) and approval routes are tracked separately so it is clear who changed what and why.

From the start, enforce persistent identifiers. Part numbers and document numbers should not depend on a filename or the designer's surname. Practical rule: the number is permanent, while version and status change. The title can be clarified, but the number must remain for the product's lifetime.

A useful minimum of metadata that almost always pays off: owner (author) and responsible department, release and effective dates, status (Draft, For Approval, Released, Obsolete), applicability (which assembly, batch, customer or project) and reason for change.

Relationships in the data model are often more important than the files themselves. A document should be linked to the product, and a part to a specific position in an assembly. A document revision should be associated with the revision of a part or assembly so a released revision does not create a patchwork of incompatible materials.

Example: when a new revision of an enclosure is released, the drawing and 3D change but the assembly specification remains the same. PLM should reflect that as an update of linked documents without changing the part number, and with a clear indicator of what is authorized for production.

Drawing revision control: how to manage revisions and statuses

In PLM for engineering data it is important to separate two similar concepts: file version and drawing revision. A file version changes with every save while an engineer edits a model or drawing. A drawing revision is issued less frequently and denotes an official release that can be used for procurement, production and inspection.

A simple working rule: change the revision only after approval, not after each save. That gives you a "working" life of the document and a separate "official" life.

To make it clear what can be done with a document right now, introduce a short set of statuses. For example: "Draft", "For Approval", "Released", "Obsolete".

Status should control permissions. In Draft the author and assigned contributors edit. In For Approval edits are locked, comments are allowed and the document can be returned for rework. In Released no one edits the source — only a new revision can be issued via the change process.

Traceability should not live in someone’s head. PLM stores who changed what, when and why, plus comments. This is critical when investigating non-conformances: you can see which revision went to production and who approved it.

A common pain is copies in email and messengers. Remove "file hand-offs" from the process and keep "status hand-offs": one source of truth in PLM, and externally provide only controlled views (for example, PDF for viewing) with the revision number and status.

Example: a designer modifies a hole in a part. While this is a file version in Draft, production does not see it. Once the document goes through approval and becomes "Released", PLM records the revision and that revision can be used safely downstream.

Applicability and replacements: so production doesn't assemble the old version

A drawing revision alone doesn't answer the shop's main question: which exact revision to use for a specific product. In PLM you set applicability: linking a revision to an order, batch or a serial-number range. This allows the same product to have different allowable configurations depending on when and for whom it is made.

Effective date and switching to a new revision

The clearest mechanism for production and procurement is an effective date (or condition) for the switch. For example: "Revision B applies to serial numbers from 01001" or "for orders confirmed after 15.03". It’s important that PLM shows not only that "a new revision is released" but also what to do with the old one: is it allowed until stock is used or forbidden immediately. This removes disputes between engineering and planning.

Short rule: applicability should be part of the approval, not a note in an email.

Component replacements: direct and reverse

Replacements are needed not only for design improvements but also for supply shortages. PLM records what a component can be replaced with (direct replacement) and for which component the current part serves as a replacement (reverse replacement). That way a planner sees allowable options and the shop does not install a "similar" part by guesswork.

In practice three things are usually enough: direct replacement rules (A can be replaced by B under given conditions), reverse replacement rules (B is acceptable instead of A, but not necessarily the other way around) and applicability constraints (only for a specific order or serial range).

Keep repair and service versions of documentation separate. They often need a different status (for example, "Service") and should not automatically flow into serial production.

If a temporary deviation is required, record it as a permission with an expiry and precise scope: batch, quantity, serial numbers, and reason. Procurement and production then understand this is an exception, not a new standard.

Change management ECR/ECO: a simple workflow

ECR/ECO is needed so any change is understandable, verifiable and repeatable. That prevents engineering edits from turning into chaos: production assembles the current revision, procurement orders the right parts, and quality knows what changed and why.

Treat ECR (Engineering Change Request) as a request to change. Anyone can initiate it — designer, manufacturing engineer, quality, service, production, procurement — whoever found a problem or saw an improvement. The request usually records the reason (defect, component replacement, cost reduction, obsolescence, customer requirement), expected effect and mandatory attachments: part and drawing revision numbers, photos or nonconformance reports, test results, a list of affected products and the required response date.

Before moving to ECO, do an impact assessment. Minimum questions: will the change affect safety and quality, production schedules, inventory and final cost? For example, replacing a connector may be simple in drawings but expensive for inventory (stock of old connectors) and for schedule (new supply in six weeks).

ECO (Engineering Change Order) is the decision: what exactly changes and how. It lists the precise objects: which drawings, which nodes in the BOM, which specifications and instructions are affected. It also sets applicability: from which serial number or date the new version applies and what to do with work in progress.

To keep the process manageable, keep the approval route short and role-based: initiator, responsible engineer, manufacturing engineer, quality, planning or production, procurement or warehouse. Each role should have a response time and a quorum rule (for example, a change cannot be released without agreement from quality and production).

Closure of the change should be as formal as its initiation. Typically you verify that PLM contains new versions and statuses, that related BOMs and documents are updated, that production has the correct applicability, and that old versions are protected from accidental release. The final step is to record the outcome: what was done, when it became effective, and which batches or orders were affected by the transition.

BOM structure: EBOM, MBOM and how to avoid confusion

A BOM in PLM is not just a parts list. It is a common language between design, manufacturing engineering, procurement and production. If you build PLM for engineering data, decide upfront which BOM types you store and how they relate.

EBOM, MBOM and SBOM: what's the difference

EBOM (Engineering BOM) shows the product from the designer’s perspective: what goes into the assembly according to drawings, which variants and which part revisions. It emphasizes designations, revisions and applicability.

MBOM (Manufacturing BOM) is for the shop: how to assemble, which operations, tooling, allowed replacements and manufacturing tolerances. MBOM often contains items absent from EBOM (consumables) and EBOM may be too "clean" for actual production.

SBOM is used when a product contains software, firmware and configurations that follow their own rules. This is especially relevant for computers, servers and AIOs: hardware may stay the same while BIOS or system images change and must be tracked separately.

How to reconcile EBOM and MBOM without manual spreadsheets

A practical approach is to keep EBOM as the source and MBOM as a derived representation with explicit links. Then the manufacturing engineer can see which EBOM nodes produced the manufacturing structure, and changes can be compared and approved directly in PLM.

Example: in a server assembly (rack, board, memory) the designer maintains EBOM according to drawings. The manufacturing engineer adds packaging, fasteners, thermal pads and approved supplier replacements in MBOM. When an ECO changes one EBOM item, the system highlights which MBOM operations and replacements are affected.

For BOMs to work for procurement and the shop floor, don't forget manufacturing attributes. Typically these are units and pack sizes, consumption rates and losses, packaging and handling units, alternatives and allowable replacements, rounding and minimum order quantities.

This prevents EBOM and MBOM from living in different files and discrepancies being discovered at the warehouse or on the assembly line.

Links to production and procurement: what to send and when

PLM for engineering data should not live isolated from the shop floor and procurement. The goal is simple: only an approved applicable revision goes to production, and procurement always knows exactly what to buy.

Production typically doesn't need all engineering documentation; it needs a clear package tied to a specific product revision: routing, operations, tooling, work instructions, inspection requirements and tolerances. This package should be linked to the MBOM and have the status "authorized for production." Then the supervisor sees one version of the truth, not a set of files from emails.

Procurement needs a different view: approved components (AVL), allowed alternatives and replacement rules, minimum order quantities, lead times and supplier constraints. If a component is "in change" (ECR/ECO), procurement must see whether it is permitted to continue buying the old revision until a cut-off date or if it is prohibited.

To avoid double interpretations, fix basic principles: one part number should be common across PLM, ERP and MES, while revision and applicability are passed as separate fields. Restrictions and cut-off dates should be stored as applicability attributes, not as comments. Inventory balances are kept in ERP, but PLM should be able to set rules like "allow use of remaining stock" or "prohibit issuing".

Integration with ERP and MES is necessary when changes are frequent and speed matters (for example, serial production). If changes are rare, controlled file exchanges and BOM exports by status may suffice. In practice manufacturers like GSE.kz often succeed with a model where ERP handles orders and stock, MES handles execution, and PLM handles drawing versions, applicability and replacement rules.

How to design PLM: a step-by-step implementation plan

Start implementation not by choosing a system but by capturing the current reality: how drawings live today, how changes are documented, where current revisions are lost, and at what moment production or procurement receives "the wrong thing." This creates a list of problems the PLM must solve first.

Next define the minimum rules of the game. Assign roles (designer, document control, manufacturing engineer, procurement), statuses (Draft, For Approval, Released, Archive), unified numbering rules and a basic set of attributes for parts and documents (designation, revision, applicability, material, owner, release date). The fewer mandatory fields at the start, the faster the team will start using the system.

To avoid drowning in scope, choose a single pilot product. Gather its EBOM and a full set of drawings as they are actually used. A good pilot is complex enough to surface typical problems but not critical to the business.

Then route changes through a clear ECR/ECO and train participants on real tasks. Discipline in four places is usually enough: ECR describes the problem, ECO records the decision and effective date or serial range, ECO links to specific objects (drawings, EBOM, replacements, applicability), and releasing a revision updates the "authorized for production" set.

When ECR/ECO and revision releases work stably on the pilot, add MBOM and exchange with ERP so procurement sees correct materials, quantities, alternatives and applicability dates. For example, at manufacturers like GSE.kz this helps synchronize drawing changes with component orders without stopping supplies or accumulating obsolete stock.

After the pilot, scale up: add new products, increase attributes and integrations only as recurring needs appear.

Common mistakes and traps when configuring PLM

The most common problem is describing processes in words but not enforcing them in statuses and rules. The system exists, but discipline does not.

Confusing revisions and drafts

If draft, approval and released revision are treated as the same "file", production and procurement will inevitably pick the wrong one. You need clear statuses (Draft, For Approval, Released, Obsolete) and rules about who and when can change data.

Automating everything at once and missing the launch

When teams configure ECR/ECO, integrations, approval routes, classifiers and reports simultaneously, the project drowns in details. Better to start with a pilot on one product and one team, stabilize release processes, then expand.

A practical sequence helps: pick one product and one type of change (e.g., material replacement), agree on statuses and roles, set up EBOM and one production report, and only then add integrations and expand reference data.

No data owner

If nobody owns catalogs (materials, units, suppliers, codes), errors accumulate for weeks. Assign owners: engineering data, item master, documents, applicability rules.

Editing BOMs manually in multiple places

When EBOM is edited in PLM while someone else tweaks the BOM in Excel or ERP, divergences become the norm. The result is extra purchases, shortages and incorrect replacements. There must be one source of truth for the product structure and other systems should consume the approved version.

Integrations without rules: data run around but nobody is the master

PLM integration with ERP and MES without clear ownership rules becomes a source of interdepartmental disputes. Decide in advance which system is master for nomenclature, who creates items, when EBOM or MBOM is sent, and what counts as "released." This is crucial for manufacturers with multiple sites and a service network, like GSE.kz.

Quick check: are rules and roles ready?

Before configuring PLM it’s useful to quickly verify whether rules and roles are ready. Without them the system will store files but won't prevent "assembled the wrong thing" or "ordered the wrong part."

First check the basics: are numbering rules unified, are statuses defined and is it clear who moves an object between statuses, is a revision issued by rule (not by renaming a file), does ECR/ECO have a clear outcome, are EBOM and MBOM separated and do owners exist for each structure.

Then check the practical: what and when leaves PLM to other systems. Production needs the MBOM, current drawings and specs, and the effective date for changes. Procurement needs codes, versions and applicability, alternatives and replacements, minimum order quantities and a flag "allowed to order."

Simple test: imagine a fastener changes in a product. Can you answer in 10 minutes which procurement orders are affected, from which serial number the replacement applies, and which shops must receive updated documents? If not, fix rules and roles first, then move them into PLM.

Practical example: changing a part without stopping supplies

In electronics manufacturing it often happens that a new board revision is released while the old one is already ordered and some stock sits in the warehouse. If you simply replace the drawing, assembly and procurement will live in different revisions and errors are likely.

First create an ECR. It records the reason (for example, component obsolescence), which assemblies are affected, and what will happen to current stock. A quick impact assessment is essential: must the line stop, are existing boards enough for a week, is there a risk of scrap?

After approval, issue an ECO. A new drawing revision appears, EBOM and MBOM are updated, and applicability is set. For example: Revision B applies to serial products from a specific date or serial number, while Revision A is allowed only to finish already-started orders.

To avoid stopping supplies, procurement gets clear rules: what changes (part number, revision, replacement), which alternatives are allowed and under what conditions, what should not be purchased anymore (stop list for the old version), and how to write off or consume remaining stock.

Close the change after verifying the first lot under the new revision: confirm tests, quality, and that assembly used the correct MBOM. Then record lessons learned: where approvals were delayed, which PLM fields were empty, and which notifications to automate next time.

Next steps: how to start and lock in results

Agree the boundaries: which products you will manage (serial, prototypes, service), which departments participate (R&D, manufacturing engineering, procurement, production, quality), and which systems already run alongside. PLM for engineering data should close the real handoffs where versions, statuses and responsibility are currently lost.

Next mark where integration is unavoidable. Typically ERP for item master and procurement, MES for shop-floor execution, warehouse systems for actual movements, and sometimes service for repairs and claims. Agree what is the single source of truth for each object: for example, revisions and applicability live in PLM, while prices and stock live in ERP.

To get value fast, define a minimal set of reports and rules. They should answer simple questions: what to assemble, from what parts, by which revision and why it changed.

A practical start looks like this: describe 3–5 key scenarios (drawing release, material replacement, emergency change, ramp-up to series), identify critical integrations and handoff points (when EBOM goes to ERP, when MBOM goes to MES), approve basic reports (product structure, applicability, ECR/ECO history, current statuses), run a pilot on one product or family with a short change cycle, and set success criteria (time to release a change, number of assembly errors, share of orders without manual clarifications).

If you need help designing processes and integrating with ERP/MES, this can be discussed with the GSE.kz team (GSE.kz) as a systems integrator with 24/7 support.