An engineering change request lands on a programme manager’s desk. The description says improved thermal efficiency on a battery pack cooling plate. The severity is High. The planned completion date is end of September.
They review it, see nothing that raises an immediate concern, and signal their approval — verbally in a gate review, or by email to the change coordinator.
Six weeks later, a re-release cycle is still running. The parent assembly has not closed. The supplier has not been notified. Nobody asked whether the geometry change needed new physical testing or whether simulation evidence was sufficient. The answer was assumed, not documented.
This is not a rare scenario. In my experience across automotive OEM and F1 programmes, it happens in one of three ways:
- The system does not surface the downstream dependency — which parts are affected, which are already Released, which parent assemblies will cascade.
- The right people are not in the approver or notifier list on the CR, so they never know the change is happening until it affects their work.
- The CR moves forward without all the required information being in place — not through negligence, but because the information needed was never visible at the moment the decision was made.
This is not a criticism of 3DEXPERIENCE. The data exists in the platform. The system enforces governance correctly. The problem is that the information is distributed across multiple apps, multiple objects, and multiple screens — and nobody assembles it into a programme-language summary at the moment a decision needs to be made.
Here is what the programme manager should have known — and where it lives in 3DX.
1. Which roles are connected to this specific change
Every engineering change touches a set of roles beyond the person who raised it. Not generic stakeholders — specific people with specific responsibilities that connect directly to that change.
3DEXPERIENCE has a Members section on every CR with an Informed Users field where these roles can be added. In practice, this field is not always populated correctly — either because the change coordinator does not know who should be on it, or because the standard approver list does not reflect the specific nature of this particular change.
This is where AI context adds real value. By reading the change content, the affected parts, the BOM structure, and the change policy, the tool can identify which roles should be in that Informed Users list — and why — before the CR is promoted.
For a cooling plate geometry revision on a battery pack programme, those roles are:
The Chief Engineer who owns the thermal requirement that triggered the change. If the geometry revision does not solve the problem, the entire re-release cycle is wasted effort. Someone needs to confirm the engineering rationale is sound before the clock starts.
The CA Owner who has been assigned the change actions. Once assigned, the CA Owner knows they have work to do — but they cannot complete their change action until the affected part revision is formally released. That sequencing dependency — child part must close before parent assembly can re-release — determines the critical path. The programme manager needs to know whether the CA Owner understands this sequence and has planned their workload accordingly.
The Supplier Quality Lead because a cooling plate is an extruded component manufactured by an external supplier. A geometry change almost certainly affects the supplier’s tooling. That is a separate lead time — potentially 8 to 12 weeks — that sits entirely outside the 3DX re-release cycle. If the supplier is not notified before the CR is approved, the programme discovers this constraint weeks later.
The Thermal Validation Engineer because the answer to one question determines whether the programme impact is 6 weeks or 14. Does this geometry change require new physical testing, or is simulation evidence sufficient? In most engineering programmes, simulation is sufficient — but that assumption needs to be confirmed and documented on the change record, not assumed and forgotten.
The Homologation Lead because battery thermal management is safety-critical. Depending on what was originally submitted for type approval, a geometry change to the cooling plate may require notification to the regulatory authority. The homologation lead knows. Nobody else does.
None of these connections are surfaced automatically when a programme manager reviews the CR. They exist in the data — in the part attributes, the BOM structure, the change policy — but assembling them into a specific, role-named list requires either experience or a tool that can read the context and apply the knowledge.
2. What the system error actually means
When a programme manager or change coordinator tries to formally promote the CR in 3DX, the system blocks them. The error message they receive is written for a PLM administrator, not a programme manager.
“Physical Product BTY-CLP-ASSY A identified as Affected Item is not consumed by any active Impact Analysis. Impact Analysis IA-0000034 should be Frozen or Completed. At least one Impact Analysis should have been performed to promote to In Approval.”
A programme manager reads this and does one of two things. They escalate it to the PLM team and wait. Or they find the quickest way to clear the blocker and move on — filling in the impact analysis as a formality rather than a genuine assessment.
Both outcomes are symptoms of the same problem. The message is technically accurate but practically useless. It does not tell the programme manager what to do, why it matters, or how long it will take to resolve.
Translated into plain English, the message means three specific things:
One — the impact analysis created for this CR has not been progressed to Frozen or Completed state. Until it is, the system will not allow the next promotion step.
Two — the parent cooling plate assembly (BTY-CLP-ASSY) has been identified as an affected item on the CR but has not been formally linked to the active impact analysis. That linkage must be made explicitly.
Three — both of these are process administration steps that can be completed today. They do not require engineering decisions. They require someone who knows where to click.
The system knows all of this. It enforces it correctly. It just does not explain it in language a programme manager can act on.
3. The timeline impact before the decision is made
When a change affects a Released part in 3DX, a re-release cycle begins the moment the change action moves into active engineering. For a single Released detail part, that cycle typically takes 2 to 4 weeks. For a Released parent assembly, 4 to 8 weeks. For a homologation-controlled assembly, 8 to 24 weeks.
The cooling plate scenario involves both a Released detail part (BTY-CLP-022) and its Released parent assembly (BTY-CLP-ASSY). Those two re-release cycles cannot run fully in parallel — the child part must reach a confirmed revision before the parent assembly can close. That sequencing adds weeks to the minimum timeline.
In this specific scenario, the planned completion date on the change order is 11 September 2026 — used here as an illustrative reference date to demonstrate the timeline conflict, not as a programme commitment. The minimum realistic re-release timeline from early August is 6 to 8 weeks. Those two numbers are already in conflict. The programme manager signalling approval in early August is approving something that cannot physically complete within the planned window.
That information is in 3DX. The planned dates are on the CO. The part states are on the BOM. The re-release sequencing is implied by the BOM structure. But none of it is assembled into a single view at the moment the decision is made.
What this means in practice — and where AI closes the gap
The data exists. The system enforces governance correctly. 3DEXPERIENCE is not failing — it is doing exactly what it was designed to do.
The gap is different. It is the gap between raw PLM data and programme-language insight. Between a system error message and a plain-English action list. Between a BOM attribute and a named role who needs to be informed.
This is where 3DX data combined with domain context knowledge and AI reasoning can bridge what is missing today. The platform holds the data. The AI holds the context — what a Released parent assembly means for a programme schedule, which roles a geometry change on an externally manufactured part should trigger, what a system error means in terms of specific corrective steps. Together they produce something neither can produce alone: a decision-ready summary at the moment a programme manager needs it.
I am building a Change Impact Analyser that reads the CR, CO, CA, and affected parts from 3DX via REST API, applies automotive programme delivery knowledge as context, and generates a plain-English assessment — before anyone clicks Approve.
It is built on real 3DX data from a real change scenario. It is in active development. And it is targeting the people who feel this problem most directly — programme managers and engineering leads who live inside 3DEXPERIENCE every day.
If this matches what you are experiencing, I would welcome a conversation.
A note on terminology
CR — Change Request. The formal record of a proposed engineering change, raised in 3DX before any work begins.
CO — Change Order. The authorisation to proceed with the change, created once the CR is approved.
CA — Change Action. The specific task assigned to an engineer to implement the change on a particular part.
Released state — a part formally locked into the programme baseline through a governance process. Changing a Released part requires a formal re-release cycle.
Impact Analysis — a formal assessment record in 3DX that must be completed before a CR can be promoted to In Approval state.
ABMTECH CONSULTING 