What an ECN is
An ECN — engineering change note — is the controlled document that carries a product change through the business: what is changing (a BOM line, a dimension, a material, a supplier part, a drawing revision), why it is changing, and from when. Instead of an engineer editing a live BOM or replacing a drawing silently, the change is raised as an ECN, routed through approval, and only takes effect when it is formally released.
The ECN exists because a manufacturing business is a web of commitments made against a specific definition of the product. Purchase orders are buying parts for it; work orders are building it; inspection is checking against its drawings; the customer approved a specific revision. Change the definition casually and every one of those commitments quietly becomes wrong. Change it through an ECN and each commitment gets the chance to catch up — deliberately, visibly, on a date.
Why uncontrolled change is so expensive
The costs of silent change rarely appear where the change was made. Stores keeps issuing the old part because nobody told the picklist. Purchasing's open PO delivers three months of a component the product no longer uses. The shop floor builds to the old drawing pinned on the machine while incoming inspection tests against the new one — or the other way around. And when a field failure arrives a year later, nobody can prove which configuration that serial number was built to.
Each incident looks like a departmental mistake; the pattern is a missing mechanism. Change control is that mechanism: one document that everything affected can reference, one approval that decides, one release date from which the new truth applies.
ECR vs ECN — request vs instruction
Formal change-management vocabulary splits the process in two: the ECR (engineering change request) proposes a change and asks whether it should happen, and the ECN (engineering change note) instructs that an approved change now takes effect. Larger organisations run them as separate documents; most SMEs run both roles through one ECN with statuses — raised (the request), approved (the decision), released (the instruction). That single-document pattern is what Fast ERP implements, and it preserves the essential property: the proposal and the effect are never the same moment.
The workflow: raise, approve, release
| Stage | What happens | Who owns it |
|---|---|---|
| Raise | ECN created describing the change, the affected items and documents, the reason and the intended effective point | Engineering / the change originator |
| Assess | Impact reviewed — BOMs, open orders, stock, process sheets, quality documents | Engineering with purchase, production, quality |
| Approve | Change-document approval: the decision that the change should happen | Authorised approvers per RBAC role |
| Release | The change takes effect — structures and revisions update from this moment | Engineering / document control |
| Track | Change dashboard shows pending, approved and released ECNs across the pipeline | Management |
Two properties make this workflow trustworthy in an ERP rather than a register. First, the ECN is a document with history — every status change is recorded, audit-trailed and attributable. Second, approval rights are role-based: who may raise and who may release is configuration, so the gate cannot be bypassed by enthusiasm.
What the released ECN actually changes
Release is the moment the change becomes real, and its reach is wider than the BOM line that triggered it:
Impact: open orders, stock and quality
The hard half of change management is not the edit — it is the world the edit lands in. A released ECN forces exactly the questions a spreadsheet lets you skip: What do we do with stock of the old part — use it up or scrap it? What about the open PO still delivering it? Which work orders in progress straddle the change, and which revision does each ship as? Does the customer's PPAP approval survive the change, or does re-submission start?
Because the ERP holds orders, stock, work orders and documents in one database, the affected records are queryable rather than guessable — and each decision becomes an explicit, recorded choice instead of an assumption discovered later. This is where integrated change control decisively beats an emailed PDF: the ECN and the things it breaks live in the same system.
Could you prove which revision last month's dispatches were built to?
Bring one real change — we will run it through raise, approval and release, and show you the before-and-after trail, in a 30-minute session.
Changes on development orders
New-product development is where change traffic peaks — iteration is the whole point of development. Fast ERP therefore supports ECNs raised against a development Order Acceptance: the churn of a part still being engineered gets the same raise-approve-release discipline as changes to a mature product, and the development order accumulates an honest history of how the design converged. When the product graduates to production, its change record comes with it — which is precisely what an IATF-16949 customer expects to see during APQP.
The change dashboard
Change management fails quietly when ECNs sit unapproved in someone's queue. The change dashboard makes the pipeline visible: what has been raised, what awaits approval, what is released, and where the bottleneck is. For management it turns "are we in control of change?" from a feeling into a screen — the same pattern the platform applies to quotations, requisitions and inspections everywhere else.
How Fast ERP implements ECN
Fast ERP builds change management into the Production & Planning module, alongside the BOMs it governs:
- ECN entry — for standard items and against development OAs, capturing the change, its reason and its targets.
- Change-document approval — the decision gate, under role-based rights with full audit trail.
- ECN release — the effect gate, from which the revised structure and revisions apply.
- Change dashboard — the pipeline view across raised, pending and released changes.
- Document control integration — drawings, control plans and PPAP packages revision-managed with the structure, via the Quality & APQP module's document subsystem.
Because the ECN, the BOM, the orders and the documents share one database, change control is not a parallel bureaucracy — it is the same system briefly pausing to agree with itself before the product moves on. For automotive and regulated suppliers, that is the difference between claiming configuration control and demonstrating it.
Frequently asked questions
What is an ECN (engineering change note)?
An ECN is the controlled document that carries a product change through the business: what is changing (a BOM line, a dimension, a material, a supplier part, a document revision), why, and from when. Instead of someone editing a live BOM or drawing silently, the change is raised as an ECN, routed through change-document approval, and only takes effect when it is formally released — so every past order keeps the revision it was built against and every affected department gets one controlled signal.
What is the difference between an ECR and an ECN?
An ECR (engineering change request) proposes a change and asks whether it should happen; an ECN (engineering change note or notice) instructs that an approved change now takes effect. Many SMEs run both roles through one ECN document with statuses — raised (the request), approved (the decision) and released (the instruction). That is the pattern Fast ERP implements: the ECN is raised, passes change-document approval, and is then released to take effect.
What does an ECN change in the ERP when it is released?
Release is the moment the change becomes real: the BOM structure or line it targets is updated, affected process sheets and specifications follow, and controlled documents — drawings, control plans, PPAP elements — move to their new revision through the document-control subsystem. Because the ECN is itself a document with history, the before-and-after is permanently recorded, and reports and audits can state exactly which revision applied on any date.
How do engineering changes affect open orders and stock?
That is the impact assessment every released ECN forces: open purchase orders may be buying the old part, stock may hold material the new revision no longer uses, work orders in progress may straddle the change, and quality documents may need re-approval. Because the ERP holds orders, stock, work orders and documents in one database, the affected records are queryable rather than guessable — and decisions like use-up-old-stock versus scrap become explicit, recorded choices.
Can an ECN be raised against a development order?
Yes. New-product development generates the highest change traffic — that is what development is. Fast ERP supports ECNs raised against a development Order Acceptance, so the churn of a part still being engineered is captured with the same discipline as changes to mature products: raised, approved, released, with the change dashboard showing what is pending at each stage.