A customer approves Rev. B on Monday.
On Tuesday, an engineer moves a mounting hole 3 mm because a cable connector is harder to reach than expected.
Someone sends the updated PDF to the sheet-metal shop with a message: “Please use this one.”
Production starts Wednesday.
Quality is still inspecting against Rev. B.
Purchasing has already ordered a bracket made to Rev. B.
Assembly is looking at a printed drawing from last Friday.
Now you do not have one engineering change.
You have four different versions of the product being manufactured at the same time.
That is exactly what Engineering Change Control is designed to prevent.
For OEM buyers developing server chassis, rackmount enclosures, industrial computers, storage systems, or other custom hardware, controlling changes before production is not administrative paperwork. It is the mechanism that separates a deliberate design revision from a factory-floor surprise.
Engineering Change Management is the controlled process used to propose, evaluate, approve, document, implement, and verify changes to an approved product configuration.
The word controlled вопросы.
Engineers change designs constantly during development. That is normal. A prototype exposes interference. A supplier recommends a different bend radius. A component becomes unavailable. Testing reveals that airflow needs improvement. The customer changes the I/O configuration.
None of those events are automatically problems.
The problem starts when the change reaches manufacturing without everyone knowing exactly:
This idea is not limited to factories making server enclosures. ISO 10007:2017 provides guidance for configuration management across products and services from concept through disposal, and ISO notes that the current 2017 edition was reviewed and confirmed in 2023.
NASA describes configuration change management in similar terms: proposed changes are systematically justified and evaluated, approved changes are incorporated, and their implementation is then verified.
That sequence is worth remembering.
Request. Evaluate. Approve. Change. Verify.
Skipping one step is where things get expensive.
Early development is forgiving.
Production is not.
When a chassis is still a CAD concept, moving a cutout may affect one file. After tooling, purchasing, inspection plans, packaging, supplier orders, work instructions, and finished inventory exist, that same change can touch ten separate systems.
The design becomes connected to money.
A change to one seemingly innocent dimension might affect:
This is why our guide on moving Engineering Revision Control from CAD through prototype validation places so much emphasis on revision management and production handoff. The prototype stage is where design assumptions should be attacked while the quantity affected is still small. The site’s existing prototype guide explicitly recommends validating real component fit, assembly sequence, structure, cooling, and service access before production approval.
Change one thing later?
Recheck what it touches.
Recently, I was browsing a manufacturing forum and came across a story from someone at a 25-person job shop that felt painfully familiar.
Engineering would release an ECO, but one change could require updates to five, six, sometimes eight separate work instructions.
The documentation could not keep up.
While somebody was rewriting those instructions, production continued using the old versions. A part would get built incorrectly. Quality might not catch the error until three days later.
Then the questions started.
Which revision was released?
Who received it?
Was purchasing notified?
Did inspection get the new dimensions?
Was the printed work instruction replaced?
Did the supplier receive the same file that production received?
The shop reportedly had PDFs scattered across a shared drive, paper copies on the production floor, and an informal “ask the guy who knows” system filling the gaps.
That last part matters.
People often imagine engineering changes failing because someone made a bad technical decision.
Frequently, the engineering decision is fine.
The information flow fails.
The CAD change might take ten minutes. Controlling every drawing, BOM, work instruction, supplier document, inspection requirement, and production release affected by that change is the real job.
Different manufacturers use the acronyms slightly differently, so buyers should never assume terminology alone proves that a supplier has a disciplined system.
Still, a typical ECR ECN ECO Workflow looks something like this:
| Сцена | Typical Document | Main Question | Production Status |
|---|---|---|---|
| 1. Change request | ECR | What needs to change, and why? | No change allowed |
| 2. Impact review | ECR / review record | What else will this change affect? | No change allowed |
| 3. Approval | Approval record | Should we proceed? | Still locked |
| 4. Engineering update | ECO | Which drawings, BOMs, models, or specs change? | New revision prepared |
| 5. Validation | Test / prototype / FAI record | Does the revised design actually work? | Hold until accepted |
| 6. Notification | ECN | Who needs the approved change? | Controlled release begins |
| 7. Implementation | ERP/MES/production release | From what order, date, serial number, or lot does it apply? | New revision active |
| 8. Verification | Inspection / audit record | Did production actually switch correctly? | Change closed |
The names are less important than the gates.
A company can call everything an “ECN” and still have excellent controls.
Another can operate PLM software with ECR, ECO, ECN, CCB, and twenty status codes yet still allow machinists to print random PDFs from email.
Fancy software does not rescue a bad release process.
The first document should explain the problem before anyone edits the released design.
That request might originate from:
A useful ECR should answer four basic questions.
What is wrong?
Be specific.
“Improve bracket” is weak.
“GPU support bracket deflects approximately 4 mm during shipping vibration test” is actionable.
What change is proposed?
Again, specific.
Increase thickness? Add a formed rib? Move the mounting point? Change material?
Why is the change needed?
This establishes intent. Without it, somebody reviewing the design six months later may “correct” the feature back to its original form because they do not understand why it changed.
How urgent is it?
A cosmetic label correction and a safety-related mechanical interference should not move through the same priority queue.
If a custom project is still being defined, many later ECRs can be prevented by locking technical inputs earlier. Our guide to the ECR ECN ECO Workflow starts with motherboard dimensions, GPU configuration, storage, power, cooling, I/O, rack constraints, service access, and commercial requirements precisely because vague inputs create revision churn downstream.
This is the step rushed teams love to skip.
Bad idea.
The engineering question is not just:
Can we make this change?
It is:
What else changes if we make it?
For a custom server chassis, imagine the customer asks to move a front USB opening 8 mm.
Simple.
Except the new position may collide with:
Now imagine material has already been cut.
The cost question changes again.
A proper review should consider at least five impact areas.
Does the change affect fit, function, interfaces, tolerance stack-up, structural strength, airflow, grounding, EMI behavior, or serviceability?
Does it require new tooling, programs, fixtures, bend setups, welding jigs, assembly methods, or process parameters?
Are existing purchase orders affected?
Can old inventory still be used?
Does a purchased component become obsolete?
Will a supplier need updated files?
Do inspection drawings, gauges, control plans, acceptance criteria, test procedures, or first-article requirements change?
Does the change alter cost, MOQ, tooling charges, production lead time, delivery date, warranty exposure, or previously agreed specifications?
NXP offers a useful real-world example of this mindset. Its published change-management process says proposed product or process changes are reviewed by a Change Board consisting of engineering, management, and quality personnel. The board examines risks, qualification plans, success criteria, and possible effects on form, fit, function, or reliability before implementation.
That is a serious review.
Not “looks okay, send it.”
Approval should come from people who own the consequences.
For a modest custom enclosure project, that may be:
For a more complex program, compliance, project management, sourcing, test engineering, or senior management may also participate.
The point is not to collect signatures for decoration.
Each approval represents a question.
Engineering: Does the revised design work?
Manufacturing: Can we build it repeatedly?
Quality: Can we inspect and verify it?
Purchasing: Are materials and supplier orders aligned?
Customer: Is this still the product we agreed to buy?
A solid Engineering Change Approval Process also connects naturally to DFM. The site’s enclosure-development guide shows why production-intent details such as bend radius, hole-to-bend distance, hardware, welding access, finishing, and assembly sequence need review before a design is treated as production ready.
Approval without that manufacturing input can simply formalize a design that still cannot be built cleanly.
This sounds obvious.
It is where many companies lose control.
An ECO may require updates to far more than a drawing.
Possible affected records include:
One document changes.
The system changes.
That is the mindset.
NASA’s configuration-management guidance explicitly calls for complete current and historical configuration documentation, unique identifiers, status tracking for proposed changes, historical traceability, version comparison, workflow management, and ideally a single source for released information.
A folder full of files named:
final.pdf
final-new.pdf
final-new2.pdf
final-customer-approved.pdf
is not revision control.
It is evidence waiting to be used against you.
The released design needs an identity.
Rev. A.
Rev. B.
Rev. C.
Or another controlled numbering system.
The specific naming convention matters less than consistency.
The old revision should remain historically traceable, but it should not remain available as an equally valid production choice.
This distinction is where Engineering Revision Control зарабатывает себе на жизнь.
A good system should tell you:
That history becomes very valuable when somebody reports a field issue 18 months later.
Without it, root-cause analysis becomes archaeology.
Approval authorizes the change.
Validation proves it works.
Those are not the same thing.
Some engineering changes can be confirmed through drawing review and dimensional inspection. Others justify a new prototype, first article, pilot build, thermal test, fit test, vibration test, load test, or customer sample.
The validation method should match the risk.
Changing a logo location?
Probably not a full prototype.
Changing the GPU support structure in a heavy AI server?
Different story.
Changing airflow openings near a fan wall?
Test it.
Changing motherboard standoff locations?
Install the real board.
Changing a rail interface?
Load the chassis and cycle the rails.
This is exactly why the existing site article on Engineering Change Order Process treats prototypes as engineering tools rather than presentation samples. It recommends checking actual component fit, assembly access, structural behavior, cooling paths, and serviceability before production release.
Find the mistake at quantity one.
That is cheap.
Find it at quantity 500?
Different meeting.
Once the revised configuration is approved and ready for implementation, the affected people need formal notification.
Именно здесь Engineering Change Notice Process should answer:
Large manufacturers formalize this carefully.
NXP states that changes affecting fit, form, function, quality, or reliability are communicated through Product Change Notices 90 days before implementation. Its notices include the effective date and affected part numbers, and its published process requires Change Board approval of qualification results before the change moves forward.
Your custom chassis project may not need a 90-day notification window.
The principle still travels well.
Notification happens before implementation, not after somebody notices the parts look different.
This is one of the most useful questions a buyer can ask:
Exactly when does the new revision start?
There should be a clean answer.
Например:
That is effectivity.
Without it, Rev. B and Rev. C can coexist in a grey zone.
Sometimes coexistence is acceptable. Maybe both revisions are fully interchangeable.
Fine.
Document that decision.
Sometimes existing inventory can be reworked.
Document that too.
Sometimes old inventory must be scrapped because the change affects fit, safety, performance, or customer requirements.
Again: document it.
The worst option is allowing the factory to decide informally as material moves through production.
Here is an unpopular opinion in our industry:
The most dangerous engineering changes are often the ones everyone calls “minor.”
A hole moves.
A tolerance changes.
A material is substituted.
A dimension is added.
A BOM line is corrected.
Someone says, “Don’t bother with a formal change. Just tell production.”
That shortcut feels efficient because the change itself is small.
The failure radius may not be.
If the released drawing changes, the controlled revision should change with it. Affected work instructions, purchasing documents, inspection requirements, supplier files, and production records should be checked before implementation.
The real test of change control is not whether the ECO has signatures.
It is whether the wrong revision has become practically impossible to manufacture.
That means old information must be controlled.
Printed copies?
Replace or destroy them.
Supplier portal?
Upload the released revision and retire the old one.
ERP attachment?
Update it.
Inspection station?
Confirm the drawing.
Laser-programming folder?
Confirm the file.
Assembly instruction?
Confirm again.
Engineering’s laptop having Rev. C does not mean the factory is building Rev. C.
Bad change control produces very ordinary factory costs.
Scrap.
Rework.
Sorting.
Reinspection.
Schedule disruption.
Premium freight.
Supplier claims.
Customer complaints.
Returns.
ASQ classifies scrap, rework, waste, and failure analysis associated with defects found before delivery as internal failure costs. It also lists repairs, warranty claims, complaints, and returns among external failure costs.
Here is the interesting number.
Согласно 2025 ASQE Insights on Excellence Cost of Quality Report, only 31% of respondents said they fully understood the impact of quality costs on their organizations’ financial performance.
Think about that for a moment.
Many companies can tell you the price of one chassis down to the cent.
Far fewer can tell you the true cost of producing 80 chassis from the wrong drawing.
The invoice for scrap is obvious.
The engineering hours, line stoppage, rescheduling, supplier calls, expedited material, inspection overtime, customer communication, and lost confidence are much harder to see.
Do not ask only, “Do you have an ECO system?”
Almost everyone will say yes.
Ask operational questions.
Who is allowed to release a drawing to production?
You want named roles, not “engineering.”
Where does production obtain the current drawing?
There should be one controlled source.
How do you prevent an operator from using an old revision?
Listen carefully to this answer.
How do you control supplier revisions?
Outsourced laser cutting, machining, plating, PCB assembly, cable production, or packaging creates another opportunity for version drift.
How do you handle work in progress when a change is approved?
Keep, rework, scrap, segregate, or use-as-is should be explicit.
How do you record the effective lot or serial number?
This matters for traceability.
Does a post-prototype change require customer reapproval?
For buyer-controlled features, it usually should.
How are inspection documents updated?
Production and quality must move together.
When sending the original project package, the site’s guide on the Engineering Change Notice Process is useful because drawings, materials, tolerances, finishes, components, quantities, quality requirements, and delivery expectations should be defined before quoting.
The clearer the original baseline, the easier later changes are to identify.
Before volume manufacturing begins, the factory should be able to point to one approved package.
For a custom chassis project, that might contain:
| Controlled Item | What Should Be Clear |
|---|---|
| 3D model | Current released revision |
| 2D drawings | Dimensions, tolerances, notes, revision |
| BOM | Correct parts and approved substitutes |
| Material specification | Grade, thickness, finish |
| Purchased components | Approved manufacturer/model or equivalent rules |
| Отделка поверхности | Color, texture, coating requirements |
| Assembly instructions | Current sequence and fasteners |
| Inspection plan | What is checked and acceptance limits |
| Test requirements | Functional or mechanical validation |
| Packaging specification | Protection, labels, accessories |
| Change history | What changed and why |
| Customer approval | Evidence that production configuration is accepted |
| Effectivity | Lot, PO, date, or serial number where revision begins |
This package becomes the production baseline.
NASA uses the same underlying concept at a much larger scale: a product baseline is approved technical documentation describing the configuration that applies during production and later life-cycle phases.
You do not need a spacecraft-sized bureaucracy to borrow the logic.
Lock the baseline.
Control deviations from it.
Some teams hear “change control” and imagine paperwork strangling engineering.
That is poor implementation.
The objective is not to prevent change.
Products improve because engineers change things.
The objective is to make sure the correct change reaches the correct people at the correct time.
Fast development and formal control can coexist.
During early concept work, CAD may change several times per day.
During prototype development, revisions can remain frequent but should become traceable.
Once the customer approves production, the gate tightens.
That is sensible.
The closer you get to mass production, the more expensive ambiguity becomes.
Before production begins, ask one question:
Could two competent employees open two different files today and both reasonably believe they have the approved production revision?
If the answer is yes, the project is not under control yet.
Fix that first.
A good Engineering Change Management system should leave little room for interpretation. The released design is identifiable. Changes have owners. Impact is reviewed. Approvals are recorded. Validation matches the level of risk. Suppliers receive the correct files. Obsolete revisions are removed from active use. The production effectivity point is recorded.
Then manufacturing starts.
That sequence can feel slower when everyone is impatient to release the purchase order.
It is usually much faster than rebuilding the order.
Engineering Change Management is the formal process for evaluating, approving, documenting, implementing, and verifying product design changes.
It keeps CAD files, drawings, BOMs, suppliers, quality records, and production instructions synchronized so that only the approved configuration reaches manufacturing.
An ECR requests a change, an ECO authorizes and defines the engineering work, and an ECN communicates the approved change.
Terminology varies between manufacturers. What matters is having clear gates for request, impact review, approval, implementation, notification, and verification.
Yes, if they alter controlled production information.
A small hole shift, tolerance adjustment, material substitution, or BOM change can affect manufacturing, purchasing, inspection, inventory, or supplier parts. The paperwork can be proportional to risk, but the revision should remain traceable.
A new revision should normally be issued when released product definition changes.
That includes changes to controlled drawings, dimensions, materials, BOMs, specifications, interfaces, or other information used to manufacture or inspect the product.
Normally, production should remain on the existing approved baseline until the new change is released.
Emergency deviations may be possible under a documented authorization process, but uncontrolled use of an unapproved revision creates traceability and quality risk.
It should receive a documented disposition: use, rework, segregate, return, or scrap.
The decision depends on interchangeability, quality, cost, safety, customer requirements, and the effective date of the new revision.
Ask how revisions are released, distributed, retired, and traced to production lots.
Also ask who approves changes, how external suppliers are notified, how work-in-process is handled, and whether post-prototype modifications require customer approval.
The biggest risk is different departments implementing the change at different times.
Engineering may have the new drawing while purchasing, production, suppliers, or quality still use the old one. Effective change control synchronizes all affected functions before release.
Mark Lee is the founder of ISTONECASE, with 20 years of experience in the server chassis industry. He specializes in OEM/ODM solutions for GPU and AI, rackmount, industrial, wallmount, NAS, Mini-ITX and multi-node chassis. His expertise supports customized hardware projects for data centers, AI computing, enterprise storage, edge computing, networking and industrial applications.
Comments
