The Revision Is Approved. Did Purchasing and Production Receive the Right Change?
Engineering control fails when the approved change does not reach the buyers, planners and operators who must act on it.
The short answer
Engineering control is not complete when the revision is approved. It is complete when the right people stop using the old truth. That means buyers, planners, stores, production, quality and suppliers all need a governed response to the approved change.
For existing Epicor users, the challenge is often less about storing revisions and more about managing the downstream effect of change.
Approval is the start of operational impact
A design or process revision can affect:
- the BOM;
- routing or work instructions;
- supplier requirements;
- existing purchase orders;
- stock already on hand;
- work in progress;
- inspection criteria;
- customer documentation.
If those consequences are not made explicit, the organization can say “the change is in Epicor” while still building, buying or inspecting against yesterday's assumption.
Separate the change from the disposition decision
One common weakness is to approve a new revision without clearly deciding what happens to affected material and open work.
Questions that must be answered include:
- Can old stock still be used?
- Can open POs continue, or must they be amended?
- Can jobs already released continue as planned?
- Does inspection need new criteria?
- Do suppliers need acknowledgement or only notification?
- Is there an effective-from date, lot, serial or order?
The revision record matters, but so does the operational disposition.
Map who needs to act
For each significant change, define the stakeholder map:
- engineering owns the technical truth;
- planning owns the effect on jobs and sequence;
- purchasing owns supplier communication and open commitments;
- stores owns stock segregation where needed;
- production owns execution against the correct version;
- quality owns inspection and release logic;
- customer-facing teams own external communication if commitments change.
This turns “revision control” into a cross-functional workflow rather than a document archive.
Watch the boundary between physical and system state
Even well-governed companies can fail at the physical boundary.
Examples:
- an old drawing printed at the workcenter remains on the board;
- revised parts arrive, but old stock remains mixed in the same location;
- buyers verbally tell suppliers about a change before the PO and acknowledgements are aligned;
- inspectors know the new requirement, but warehouse labels still reflect old assumptions.
The practical test is simple: walk the process and see whether the physical environment matches the approved revision.
Treat open supply carefully
Purchasing is often the quiet risk point in engineering change. Open orders may already be acknowledged, in transit or partly received. The change may alter dimensions, packaging, test requirements or labeling.
A useful review asks for every impacted purchase order:
- what quantity is already complete;
- what quantity is in transit;
- what quantity can still be changed;
- whether supplier confirmation is required;
- whether incoming stock must be quarantined or re-identified.
The sooner this is explicit, the lower the downstream confusion.
Keep production from discovering change too late
Production should not be the place where a revision problem is first discovered physically. If an operator finds that parts, work instructions and job packet no longer agree, the organization is already in reactive mode.
Use governed release rules so a job starts only when the required technical truth, material and instructions are aligned enough to run responsibly.
Where ACC can help
ACC's value here is practical rather than theoretical: helping existing Epicor users design the cross-functional workflow around change, especially where industry-specific behavior, supplier coordination or warehouse execution creates complexity.
Where scanning, stock segregation or receiving controls matter, ACC's experience around Epicor-linked execution can also help keep physical flow close to system truth.
Run a last-change retrospective
Take the most recent meaningful revision and reconstruct the timeline:
- when was the change proposed;
- when was it approved;
- when did Epicor reflect it;
- when were buyers told;
- when were suppliers told;
- when was old stock disposition decided;
- when did production first work to the new truth;
- when did quality inspect to the new truth.
Then identify where latency or ambiguity appeared. This creates a concrete improvement map.
Add effectivity logic to everyday control
Many revision problems come from assuming that “new approved revision” is enough direction. In practice, users need effectivity logic they can operate with. That may be by date, by job release, by lot/serial range, by customer order or by stock disposition.
The exact method matters less than the clarity. People should be able to answer, without debate:
- from what point is the new truth mandatory;
- what legacy material remains acceptable;
- where the boundary between old and new is physically controlled.
Measure the health of change execution
Useful practical measures include:
- time from approval to full downstream communication;
- percentage of affected open orders explicitly reviewed;
- frequency of mixed-revision incidents;
- rework or scrap caused by outdated instructions;
- supplier acknowledgement cycle time for affected POs.
These indicators show whether the change process is being lived, not merely documented.
Clarify who closes the loop
A revision workflow often begins clearly in engineering, but closes ambiguously in operations. To avoid that, define closure criteria. For a significant change, closure may mean that:
- affected buyers have updated suppliers or open POs;
- impacted stock has a clear use/disposition rule;
- released or future jobs are aligned to the correct revision;
- work instructions or packets at the workface are current;
- inspection and quality logic have been updated.
When closure is defined, management can distinguish “approved” from “fully landed”.
Useful measures for revision effectiveness
In addition to local engineering metrics, consider:
- time from approval to downstream communication complete;
- percentage of impacted open supply explicitly reviewed;
- incidents of mixed-revision work or stock;
- rework or scrap caused by outdated instructions;
- supplier acknowledgement cycle time for revised requirements.
These indicators reveal whether the business is controlling the operational effect of change, not merely documenting it.
Part of the wider Epicor coordination series
This cluster supports the pillar Epicor Connects the Business. Where Does Coordination Still Break Down?. Engineering control becomes a coordination issue the moment one approved change must be translated into new action by multiple teams.
Warning signs that change control is leaking
A company should investigate when users repeatedly ask which version is correct, when old and new stock are found together, when suppliers continue shipping superseded parts, or when production discovers the change physically rather than through controlled release. These are all signs that the approved revision did not travel with enough operational clarity.
The remedy is rarely more documentation by itself. It is a stronger combination of disposition logic, physical segregation, communication discipline and visible closure criteria.
Use one recent change as a design case
Teams often learn fastest when they take one meaningful change and use it as a full design case. Identify every record touched, every physical control required and every place where ambiguity could have appeared. Then redesign the sequence so the next change of similar type lands more cleanly. That is usually more valuable than trying to fix every possible scenario at once.
Standardize the review questions
For recurring change types, standard review questions save time: what stock is affected, what open supply is affected, what work in process is affected, what customer or quality implication exists, and what evidence proves closure. A common checklist makes revision response more reliable across teams.
Frequently asked questions
Isn't revision control mainly an engineering matter?
No. Engineering owns the technical intent, but the business consequence is cross-functional.
Do we always need hard cut-over rules?
Not always. Some changes allow controlled overlap. The key is that the overlap must be deliberate and explicit.
What is the biggest practical risk?
Usually the ungoverned mixture of old and new truth across stock, work in process and supplier commitments.
Can Epicor solve this without process work?
No ERP can solve it without process work. Epicor can provide the backbone, but ownership, evidence and exception handling still matter.
Where does ACC fit?
ACC can support Epicor users in workflow design, industry-specific operating logic, supplier/warehouse coordination and implementation governance around change.
The right revision must travel
A revision is valuable only when the whole organization stops making yesterday's decision. That is the operational meaning of change control.