CUSTOM APPLICATIONS

Engineering Change Control for Manufacturers: Getting the Right Revision to the Floor

October 28, 2026 • 7 min read
AUTHOR

Kyo Logic

Expert

Engineering change control is the process that decides how a drawing or spec change gets requested, approved, and released, so every open job runs to the current revision. When it works, the machinist never has to wonder which print is right. When it does not, the floor finds out the hard way.

Here is the kind of Tuesday we hear about from contract machining shops. The engineer updated a bracket drawing to Rev C last week, moving one hole 0.020” for a customer fit issue. The traveler (the paper packet that follows a job through the shop) still holds a Rev B print from when the job was released. The operator runs 200 parts to Rev B. Inspection catches it two days later, after the parts have already gone to the plater.

Key takeaways

  • Map your current change path, from first email to operator’s print, and count the handoffs.
  • Give every ECR a home and a status, even if the first version is a shared form.
  • Record the revision on every released job so a change can find the work it affects.
  • Pull obsolete prints from the floor the day a new revision releases.
  • Attach customer-specific requirements to the order so they travel with the job.

How does the wrong revision reach a machine?

Almost never through carelessness. It happens because the revision lives in one place and the work lives in another.

  • The CAD folder has the new drawing, but nothing tells the scheduler that three released jobs use it.
  • Printed travelers outlive the revision they were printed against.
  • The customer’s change arrives by email to whoever answered the phone, and stays in that inbox.
  • Approval is a hallway conversation, so nobody can say later who signed off or when.

The cost shows up as scrap, rework, rush material, and a hard customer conversation. On an audited part, add a nonconformance report.

Give every change request a record of its own

The fix starts with two plain definitions. An ECR (engineering change request) is the formal ask: someone says “this part should change, and here is why.” An ECO (engineering change order) is the approved, released change: the decision that the new revision is official and what happens to work in progress.

An ECR can come from anyone, including the customer or an operator who sees a tolerance that cannot be held. An ECO is released by the people who own the design and the schedule.

A lightweight flow can look like this:

Someone submits an ECR with the part, current revision, reason, and markup

↓

Engineering reviews and drafts the new revision

↓

Quality and production weigh in on impact (tooling, inspection, open jobs)

↓

Approver signs off and the ECO is released

↓

New revision becomes the only one available for new work, and affected jobs are flagged

Nothing here needs a large team. It needs one place where the request lives, a clear status (submitted, in review, approved, released), and a named approver.

Linking revisions to open jobs is where control actually happens

When each job records the part number and revision it was released against, releasing an ECO can produce a list: every open job, every unshipped order, and every kitted traveler still pointing at the old revision. Each one gets a decision. Let it finish on Rev B because the customer agreed. Stop it and reprint. Rework the parts already made.

That decision gets recorded on the job, so nobody has to remember it. Kyo’s article on customizing production steps and requirements shows how routing and requirements can be tied to the specific job, which is the same structure a revision link depends on.

One shop rule needs no software at all: pull obsolete prints the day they are replaced instead of filing them next to the new ones.

Where do customer-specific requirements belong?

On the order, attached to the revision they apply to. Contract manufacturers often run one part for two customers with different marking or inspection rules. If those rules live in a sales rep’s notes, a revision change can quietly drop them.

Kyo’s post on reviewing and adopting requirements for specific orders covers how to capture those terms at order entry so they travel with the job. When an ECO releases, the change record should show whether any customer-specific requirement is affected, and who confirmed it.

The audit trail comes from the records you already keep

If you are certified to a quality standard, or your customers audit you against one, expect questions about how drawing revisions are controlled and how you know the floor used the right one. The exact requirements depend on the standard and the customer, so confirm them with your quality lead or registrar.

A change process built as records can answer many of those questions directly. Each ECR and ECO carries who asked, who approved, when it released, and what was decided for each affected job. Kyo’s article on maintaining historical records for future reference and replication shows why that history pays off when a part is reordered years later.

This can be built in many tools. A PLM (product lifecycle management) system may fit if you have a large engineering team. Some manufacturers do better with a focused workflow connected to the job and order data they already run, and a custom Claris FileMaker app is one way to build that without replacing the systems that work.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We can help shops connect engineering changes to the jobs and orders they affect, so the floor builds to the released revision.

Frequently asked questions

What is the difference between an ECR and an ECO?

An ECR (engineering change request) proposes a change and explains why. An ECO (engineering change order) is the approved, released change that makes the new revision official and decides what happens to work already in progress.

Do we need PLM software for engineering change control?

Not necessarily. Many manufacturers only need change requests, approvals, and released revisions linked to their jobs and orders, which a focused custom workflow can handle.

What should happen to jobs already running when a revision changes?

Each affected job needs a recorded decision: finish to the old revision with customer agreement, stop and reprint, or rework.

If revisions in your shop still travel by email and memory, book a free 20-minute Data Health Check and we will look at where the handoffs break.

Ready to see what’s possible?

Let’s talk about how we can help you streamline, scale, or innovate—on your terms.

Start the Conversation