An engineer spots a problem: a bracket that cracks under load. The fix takes an afternoon in CAD.
Getting that fix onto the production line takes months.
That isn't an exaggeration. In one manufacturers' survey, minor engineering changes took about 4 days on average, medium changes about 17 days, and major changes about 142 days. And 73% of the organizations surveyed didn't know what their changes actually cost. (MAPI survey, via DocuWare)
Those figures come from a secondary source, so treat them as a guide. But ask any manufacturing engineer whether they sound right, and watch them nod.
Where the time goes
Very little of that time is engineering. Most of it is waiting:
- Unclear routing. Nobody is sure who needs to approve this particular change, so it goes to everyone, or to the wrong person.
- Email approvals. The request sits in an inbox behind 200 other emails.
- Manual impact analysis. Someone has to work out by hand where the part is used, how much stock is on the shelf and which open orders are affected.
- Missing information. An approver asks a question, the request goes back, and the clock restarts.
- No deadlines. Nothing escalates when a review is late, so nothing is ever late, officially.
- No visibility. Ask "where is change 1042?" and someone has to go and find out.
The real cost of a slow change
A slow change isn't just slow. While it waits:
- Production keeps building the old revision, and every unit may need rework or scrap later.
- Obsolete stock keeps arriving, because purchasing doesn't know the part is changing.
- Customers wait for fixes and improvements they were promised.
- Engineers lose time chasing approvals instead of engineering.
What a modern change process looks like
| Step | How it usually works | With a change workflow beside your PLM |
|---|---|---|
| Request | An email with an attachment | One form, linked to the exact part and revision in PLM |
| Impact review | Worked out by hand | Where-used from PLM, stock and open orders from ERP, gathered automatically |
| Routing | "Who should see this?" | Approvers picked by role from your org chart, in parallel where possible |
| Reviews | Waiting in inboxes | Deadlines in working hours, with automatic escalation |
| Approvals | Reply-all | Approve from the task inbox, email, Teams or Slack |
| Release | Someone updates each system | Results written back to PLM and ERP, with a full audit trail |
The engineering stays exactly as it is. What changes is everything around it.
Measure what matters
Once changes run through one workflow, you can finally see the numbers that matter:
- Cycle time by change class: minor, medium and major
- Where changes wait, and for whom
- On-time rate against your target for each class
- Cost per change, including scrap and rework while it was open
Most companies can't answer these today. A change workflow answers them by default.
Built beside your PLM with Defender
A change workflow is a focused module, not a new PLM. Defender builds it beside the system you already run:
- Workflows built in. The rx1 runtime includes a workflow engine with approvers from the org chart, deadlines, escalation and parallel reviews.
- Test process changes safely. When you change the process, real past cases can be replayed against the new version before it goes live.
- Connected, not copied. Part and revision data stays in PLM. Stock and orders stay in ERP.
- Governed delivery. AI agents do the delivery work, and Triyas experts review and approve every stage.
The module runs in your own cloud or data center, and you own all of the code.
For the bigger picture, read your PLM holds the design: who runs the process around it?
Cut your engineering change cycle time
We'll map your current change process and prepare the complete requirements specification for a change workflow beside your PLM, at no cost.
Register for Defender
