An engineering change request (ECR) proposes a change and explains why. An engineering change order (ECO) authorizes what will change and when. An engineering change notice (ECN) tells affected teams what has been released and what they must do. In electronics manufacturing, these steps keep the buyer and factory on the same product revision.
| Factor | ECR | ECO | ECN |
|---|---|---|---|
| Purpose | Propose a change | Authorize and define the change | Announce the approved change |
| Answers | Should we change this, and why? | What exactly changes, and from when? | Who needs to act on it? |
| Typical author | Engineering, quality, production, supplier, or customer | Engineering or change control board | Engineering or document control |
| Key contents | Problem, proposed fix, estimated impact | Affected parts, old and new revisions, effectivity, stock disposition, approvals | Change summary, effective point, actions for each team |
| Who acts on it | Reviewers | Engineering and manufacturing | Production, quality, procurement, and suppliers |
How Do ECR, ECO, and ECN Compare at a Glance?
The table shows a useful three-step model: propose, authorize, communicate. It is a way to assign responsibilities, not a claim that every quality standard requires three separate forms. A change can be approved in a product team’s system and still fail at the factory if purchasing, work instructions, test limits, or incoming material records remain on the old revision.
SAE’s EIA-649C configuration management standard explicitly allows different terminology across product environments and addresses relationships between a customer and supplier. The useful common ground is knowing who may propose, authorize, release, and verify a changed configuration.
That distinction matters when the design owner and manufacturer are different companies. The buyer may consider a change complete once engineering signs it, while the factory may be waiting for a released drawing and an effective lot number. State what document or system event gives each side permission to act.
What Is an Engineering Change Request (ECR)?
An ECR records a proposed change before anyone assumes it is approved. It should describe the problem or opportunity, affected product and part numbers, a possible solution, and the impact of doing nothing. A supplier may submit one when a component reaches end of life. A factory may submit one after finding an assembly issue, while a field team may submit one after repeated failures.
The request is the place to investigate consequences. Replacing a connector might affect the PCB footprint, enclosure opening, mating cable, assembly fixture, and test procedure. Reviewers should estimate cost, schedule, remaining stock, validation work, and any customer or regulatory impact. An ECR can be approved, deferred, or rejected; submission alone does not authorize a substitute part on the line.
NASA’s configuration management guidance describes systematic proposal, justification, and evaluation before approved changes are incorporated and their implementation verified. That sequence fits commercial electronics even though a small product team will use lighter paperwork than a space program.
During early new product introduction, many ideas are still being tested. An engineer can explore a layout improvement without opening a formal request for every sketch. Once a design, bill of materials, or build process is released to the factory, however, proposed changes need a traceable entry point. Early design for manufacturing review can reduce the number of late requests that arrive after tooling or materials are committed.
What Does the Engineering Change Order (ECO) Add?
The ECO turns an accepted proposal into controlled implementation instructions. It names the released files to replace, old and new revisions, approving people, required checks, and the exact point when the new design applies. The separate engineering change order guide covers those fields in detail; here the key distinction is that the ECR asks for a decision and the ECO records the authorized answer.
Effectivity deserves more attention than a date in the corner of a PDF. If 700 old-revision boards are already assembled and 300 new-revision PCBs are on order, the ECO should say whether the change starts with a purchase order, a lot, or a serial number. It must also tell the factory whether to use, rework, hold, return, or scrap existing material. Without that decision, two valid revisions may be mixed in one shipment.
The approvals should match the risk. Engineering may approve electrical fit, quality may approve inspection and validation, procurement may confirm supply, and the product owner may need to approve cost or customer-facing changes. ISO and IAF guidance on ISO 9001 change control points to review and control of design and production changes and making relevant people aware of changed requirements. It does not prescribe an ECR-ECO-ECN form set.
What Is an Engineering Change Notice (ECN)?
In the three-document model used here, the ECN is the controlled communication that an approved change has been released. It carries the change identifier, new revision, effective lot or serial number, and the action required from each recipient. Production may need a new work instruction; procurement may need a new approved manufacturer part number; quality may need updated incoming inspection criteria.
A notice should go to people who can act, not merely to a distribution list. The factory needs to acknowledge receipt, replace obsolete documents at the point of use, update its planning system, and identify the first affected build. A buyer should ask for that acknowledgment rather than treating an email sent at 5 p.m. as proof of a line change the next morning.
Terminology varies. PTC describes an approved ECR leading to an ECN that may also be called an ECO; its PLM workflows can use an ECN to plan and execute a change. That differs from the separate notice-after-order convention in this article. Neither naming system removes the need for authorization and communication. In a buyer-factory agreement, define what each term means, who approves it, and which document releases the production revision.
Do Small Hardware Teams Need All Three?
No. They need the three decisions and handoffs, but they do not necessarily need three document templates or an expensive PLM system. A startup may use one numbered change record with sections for request, impact review, approval, effectivity, and release notification. A spreadsheet can track status while controlled files live in a shared document system, provided access and revision rules are clear.
Combining forms works only if the states remain distinct. “Proposed” should not look like “approved,” and “approved” should not silently mean “implemented.” Require named approvers and dates, then record who received the release notice and which lot first used the changed files. Keep superseded revisions retrievable for warranty and field investigations.
NASA’s change-control sequence separates evaluation, approval, incorporation, and verification. Those are process controls rather than a mandated count of forms. For a small team, a single well-run record can be safer than three impressive-looking PDFs that disagree about the revision.
Use a higher approval threshold for changes with larger consequences. A resistor value swap may need circuit and test review; a mains-safety change may also affect certification and fielded units. A product team should define those thresholds in advance so urgency at the factory does not decide who can authorize what.
How Does the Change Process Work With a Contract Manufacturer?
Start by giving the factory a clear way to raise an ECR. A component end-of-life alert, yield problem, tooling issue, or repeated test failure may first appear in Taiwan or China while the design team is elsewhere. The factory should send the affected part and revision, evidence, available stock, proposed remedy, and date by which a decision is needed. It should not buy the substitute or edit a controlled build package while the proposal is under review.
The design owner then evaluates the change with engineering, quality, procurement, and the factory. Ask whether an alternate component changes the footprint, electrical margin, firmware, thermal behavior, regulatory evidence, or supplier qualification. During new product introduction, the same review should identify whether prototype or validation results must be repeated before a production release.
After approval, issue an ECO with the final files and a defined effectivity point. The factory should confirm that its bill of materials, purchasing records, assembly instructions, programs, fixtures, test limits, and quality plan now match the same revision. If old material exists, the order should give a disposition for loose parts, work in process, finished stock, and any units already shipped.
Send the ECN to the people who must carry out the change, including the factory’s document control, production supervisor, buyer, and quality lead. Record their acknowledgment and the first lot or serial number built under the new revision. PTC’s description of change management likewise connects change notices with implementation plans and validation before data release. The software labels can differ; the receiving team’s action cannot be left vague.
Check the first changed units against the order, not only against a functional pass result. Verify the new component identity, drawing revision, programmed firmware, affected test results, and labels. If the ECN says the change begins with lot 42, records for lot 42 should prove it. If a mix-up is found, hold the affected range before it becomes a field traceability problem.
Titoma’s value in a cross-border build is helping the client’s released design reach purchasing, production, inspection, and shipment as one controlled revision. Ask any manufacturing partner to show the ECR decision, ECO approval, ECN acknowledgment, and first changed unit on a real example. If that chain cannot be shown, the process is still a collection of documents rather than a controlled change.
