Engineering Change Management: Design Changes Get Lost in Email and Spreadsheets

What is engineering change management?

The short version: engineering change management (ECM) is the controlled process for proposing, reviewing, approving, and implementing a change to a product design.

So it is the discipline that carries a change to every system and person it touches, in order, with a record of who decided what.

What does engineering change management mean in practice?

It means treating a design change as a controlled event that follows a defined path, rather than an email. A change moves through a few clear stages:

• It starts as a problem or an idea: a field failure, a cost saving, a supplier part going obsolete.
• Someone assesses its cost and impact: then the right people approve or reject it.
• It flows downstream: into the drawings, the bill of materials, procurement, and the shop floor.

So the point of ECM is traceability. Every revision has a reason, an owner, and an approval behind it. That matters in regulated sectors, from medical devices to automotive, where you must prove why a part changed and when.

What is the difference between an ECR, an ECO, and an ECN?

Most change processes run on three documents, and the terms get muddled constantly. They are simply three stages of the same change:

1. Engineering change request (ECR): the opening question. It flags a problem or an improvement and asks whether a change is worth making, before anyone commits engineering time.
2. Engineering change order (ECO): the approved plan. It spells out what will change, names the affected parts, drawings, and BOM lines, and routes the change for formal sign-off.
3. Engineering change notice (ECN): the announcement. It tells production, procurement, quality, and suppliers that the change is live, and which revision to build from now.

So the ECR asks, the ECO decides, and the ECN informs. Get those three flowing and most of the chaos disappears.

Why do design changes still get lost in email and spreadsheets?

Because email and spreadsheets have no concept of a current revision. So the same failure keeps repeating, in a few predictable ways:

• No current version: a drawing is right when you send it and stale the moment the next change lands, and nobody flags it.
• Two sources of truth: two people work from two revisions, so the wrong one reaches the shop floor.
• No trace: the information is all there, yet scattered and impossible to follow back to a decision.

The error then surfaces at the worst possible moment, on the shop floor, once the part has already been built or bought.

What does engineering change management software do?

ECM software replaces that scatter with one set of controlled change workflows, often inside a cloud PLM system. In one place it:

• Holds the ECR, ECO, and ECN together: the whole change lives in a single record.
• Routes approval processes automatically: each change reaches the right reviewers without waiting in an inbox.
• Ties each change to the parts it affects: with full document control across drawings, BOM lines, and specs.
• Keeps full audit trails: so everyone sees the current revision and the reason behind it.

The engineering change management process, step by step

Most engineering change processes follow the same broad path, whether they run on paper, in a spreadsheet, or in dedicated software. The steps matter, because a change can stall or leak at any one of them:

1. Identify the change: someone spots a problem or an improvement, from a field failure to a supplier part going obsolete.
2. Raise a request (ECR): the team writes up the change and weighs its feasibility, cost, and impact before engineering commits.
3. Review and approve: a change control board of engineering, quality, operations, and procurement judges the request and decides.
4. Plan the change (ECO): engineering details the approved change against every affected part, drawing, and BOM line.
5. Implement: the team updates the drawings, CAD models, and the BOM, then releases the new revision.
6. Notify and verify (ECN): the notice reaches production, suppliers, and documentation, and the team confirms the change as built.

Notice how many functions a single change touches. So the process is mostly about coordination across teams and that breaks down when it runs on shared drives and reply-all threads.

Why poorly managed changes cost so much

A change caught early is cheap and late it gets expensive. In product lifecycle management this is the rule of ten: with each successive phase, the effort to implement a change rises by roughly a factor of ten.

So a tweak at the concept stage costs almost nothing. The same tweak after you cut tooling, buy the parts, or ship units can cost a fortune in retooling, scrap, and delay.

And the cost transfers as well. As the German PLM specialist CENIT points out, a single change ripples across purchasing, production, documentation, and sales. Change one material. Now procurement has to resource it, technical writers have to redo the manuals, and planning has to reschedule.

So the hidden cost of weak change management is rarely one big number. It shows up as a scatter of small ones:

• Expedited shipments: paying a premium to claw back time lost to a late change.
• Reworked or scrapped batches: parts built to a revision that had already moved on.
• Stalled decisions: hours lost while teams argue over which drawing was right.

The root cause is almost always the same three things:

• no standard process,
• poor communication between stakeholders,
• and no single source of truth.

What to look for in engineering change management software

Most ECM tools live inside a wider product lifecycle management (PLM) or quality system, and the good ones share a common set of capabilities. When you weigh up options, these features separate proper change control from a glorified form:

1. Automated approval routing: send each change to the right reviewers by type, priority, or product line, so nothing waits in an inbox for a week.
2. Revision and BOM control: tie every change to the exact parts, drawings, and bill of materials lines it affects, so BOM updates stay in step with one current revision.
3. Full audit trail: a complete record of who requested, reviewed, and approved each change, which ISO, FDA, and automotive rules all demand.
4. Impact visibility: a clear view of everything a proposed change touches, before approval.
5. PLM and ERP integration: push the change into procurement, planning, and the shop floor, instead of stopping at the engineering wall.
6. Supplier collaboration: let external partners see the current revision and respond in the same system.

So the test is simple. Does the tool keep one version of the truth and push it to everyone who needs it? If a change can still slip through, the software has not solved the core problem.

Where AI is changing engineering change management

Here is the part the established tools are only starting to reach. A workflow tool controls the change once someone has written it up. But most of the pain sits earlier, in turning a changed drawing into structured, usable data. That is where AI comes in.

Reading a technical drawing and turning it into structured data is our flagship focus, the work we call AI4CAD. Applied to change management, a handful of use cases return value quickly:

• Reading the changed drawing: AI pulls dimensions, tolerances, materials, and notes from a revised PDF or CAD file. It hands them downstream as structured data, so a change stops living as an attachment.
• Comparing revisions: AI checks the new drawing against the old and flags exactly what changed, so a reviewer sees the delta instead of hunting for it by eye.
• Flagging affected parts: read against your bill of materials, AI surfaces which components, assemblies, and documents a change is likely to hit. That feeds the impact assessment.
• Drafting the paperwork: AI pre-fills the ECR or ECO with the extracted detail, so the engineer checks and approves rather than retypes.
• Knowledge retrieval: engineers ask in plain language whether a similar change came up before, and pull the reasoning and outcome from past projects.

The change decision stays with people. AI clears the manual data work that lets a change slip through unseen, and hands the reviewer a clear, structured picture to act on.

Where AI does not replace engineering judgement

AI speeds the information work around a change, but the change decision itself stays human. So it is worth being precise about the limits:

• The approval decision: whether a change is worth its cost and risk is a judgement call across engineering, quality, and commercial trade-offs. AI informs and the people in the room make the decision.
• Safety and failure risk: judging what a change might do to a safety margin or a failure mode rests on engineering experience, which pattern-matching cannot supply.
• Novel design work: when the change is a genuinely new solution, AI has little precedent to learn from, so the engineering stays manual.
• Accountability: in regulated industries a named person signs off a change. AI cannot carry that responsibility, and should not.

So the framing is a division of labour: machine on the repetition, human on the decision. AI reads, compares, and flags. Your engineers weigh the risk and own the call.

Best practices for engineering change management

Software helps, but the discipline and cross functional collaboration around it decide whether it works. The manufacturers who run change well tend to share the same habits:

1. Define one clear process: agree how a change gets proposed, reviewed, approved, and communicated, then use it every time, so nobody invents their own route.
2. Use a change control board: bring engineering, quality, operations, and procurement to the review, so impact gets judged from every angle before approval.
3. Keep one source of truth: hold the current revision in one system and not in inboxes and folders, so the version question never comes up.
4. Assess impact before approving: map what a change touches across the BOM, suppliers, and documentation up front.
5. Connect to your other systems: a change that reaches the drawing but not the ERP or the supplier is only half done.

This is process discipline plus a system that enforces it. Which is exactly what good ECM software and, increasingly, AI are there to support.

How to get started without overreaching

You do not need to replace your whole PLM to fix change management. The manufacturers who succeed start narrow, at the point where changes leak, and build from there.

So begin by finding where your changes get lost today. For most teams that is the handover from a revised drawing to everyone downstream. Which is exactly where reading drawings into structured data pays back first.

Keep a human in the loop on every approval and connect the change to your real systems, so it does not die in a spreadsheet.

You do not have to perfect every process before you begin. Start at the leak, prove the value, then widen out, backed by custom machine learning development where off-the-shelf tools fall short.

Frequently Asked Questions

Q1: What is engineering change management?

A1: Engineering change management is the controlled process for proposing, reviewing, approving, and implementing a change to a product design. So it carries a change to every affected system and person, in order, with a full record of who approved what and why.

Q2: What is the difference between an ECR, an ECO, and an ECN?

A2: They are three stages of one change. An engineering change request (ECR) proposes and justifies a change. An engineering change order (ECO) is the approved, detailed plan. An engineering change notice (ECN) tells production, procurement, and suppliers the change is live, and which revision to build.

Q3: Why do design changes get lost in email and spreadsheets?

A3: Because email and spreadsheets have no concept of a current revision. A drawing sent by email goes stale the moment the next change lands, and nobody flags it. So two people end up working from two versions, and the error often surfaces only on the shop floor.

What’s this worth to your team?

Q4: What does engineering change management software do?

A4: It replaces scattered files with one controlled workflow. The software holds the ECR, ECO, and ECN together, routes approvals, ties each change to the parts it affects, and keeps a full audit trail. So everyone sees the current revision and why it changed.

Q5: How does AI help with engineering change management?

A5: AI attacks the manual data work around a change. It reads a revised drawing into structured data, compares it against the old revision to flag what changed, and surfaces which parts a change will hit. So it feeds the review, while the approval stays with your engineers.

Q6: Can AI approve engineering changes automatically?

A6: No, and it should not. Whether a change is worth its cost and risk is a judgement call, and in regulated industries a named person must sign it off. AI informs the decision by extracting and comparing the data, but the accountability stays human.

Q7: Do we need a full PLM system to manage engineering changes?

A7: Not to start. Many teams first fix the point where changes leak, usually the handover from a revised drawing to everyone downstream. You can improve that with focused tooling and AI, then connect to a wider PLM or ERP as the process matures.