FMEA that stays connected to the design
FMEA is done well once, in a spreadsheet, by people who care, and then it detaches from the design and slowly becomes a document produced for audits.
What changes when it is linked
A row in an FMEA spreadsheet names a function, a failure mode, effects, causes and controls. It names them in text, which means the connection to the actual item and the actual characteristic exists only in the reader's head.
Here, a failure mode attaches to the object it concerns: an item revision, a specific characteristic on a specification, or a process step in a routing. The row is not describing a part; it is attached to the part.
Everything useful follows from that. When a characteristic's limit changes, the failure modes referencing it are flagged as needing review. When a component is substituted, the rows citing its properties surface. When a control is a specific inspection, the inspection plan and the FMEA cannot disagree, because they reference the same characteristic.
Severity, occurrence, detection — and what Manufacturing PLM does not do with them
The three ratings and the RPN they multiply into are held as typed fields with the rating scale your organisation uses, because those scales differ by industry and by customer and there is no useful universal one.
Manufacturing PLM does not assign ratings. Severity is an engineering judgement about consequence, occurrence is a judgement informed by data that is frequently absent, and detection is a judgement about a control's real effectiveness rather than its intended one. Software that produced these numbers would be producing confidence, not analysis.
What it does is make the inputs visible. A row's occurrence rating sits next to the nonconformance history for that item, so a rating of 2 on a component with eleven nonconformances in eighteen months is visibly questionable. The judgement stays human; the evidence stops being somewhere else.
AIAG-VDA action priority is supported alongside RPN, and which one a tenant uses is configuration. Both are held; neither is calculated into a decision.
The failure it prevents
A DFMEA identifies a failure mode with severity 9, mitigated by a design control: a specific wall thickness that keeps the part above its stress limit. The rating drops to an acceptable level and the row closes.
Two years later, a cost reduction thins that wall. The change is reviewed by people who were not in the FMEA session, the reasoning behind the original thickness is in a spreadsheet nobody opened, and the change is approved.
The FMEA was correct and invisible. Linked to the characteristic, the same change would have surfaced the row before approval — severity 9, this control, this is why the thickness is what it is. That is the entire value proposition, and it is unavailable to any FMEA held as a document.
How it meets the rest of the product
Impact analysis includes FMEA rows. A change touching a characteristic reports the failure modes whose controls depend on it, in the same view as affected products and open orders, so the reviewer sees it without going to look for it.
Quality records close the loop from the other direction. A nonconformance against a characteristic surfaces the failure modes that predicted it — or reveals that none did, which is the more interesting outcome and the one that should trigger an FMEA revision.
Control plans generate from the FMEA's detection controls rather than being maintained beside it, so the control plan and the FMEA cannot drift apart. They are the same information rendered for two audiences.
Revision control applies to the FMEA itself. A row's rating changing is a change to a controlled document with an actor and a date, which is what makes the question of what the analysis said at the time of a decision answerable — and it is asked more often than teams expect.
Reuse works the way it should. A failure mode identified on one item is visible when a similar item is classified the same way, so the next programme starts from what the last one learned rather than from an empty template and somebody's memory of the session.
How it meets your ERP
The ERP has no place for an FMEA and should not acquire one. What crosses is narrower and specific: characteristics designated as critical or significant in the FMEA are marked as such on the item, and that designation is what an ERP or MES uses to enforce inspection at receipt or in process.
That single flag is the operational output of the whole analysis. An FMEA that identifies a critical characteristic and does not cause that characteristic to be inspected has produced a document rather than a control.
Nonconformance data flows the other way where the integration exists, feeding the occurrence evidence described above. It informs the rating; it does not set it.
Where the boundary is
Manufacturing PLM does not calculate or propose severity, occurrence or detection ratings. It holds them, shows the evidence beside them, and flags rows whose basis has changed. The analysis is the team's.
It also does not run the FMEA session. Cross-functional review is the part of FMEA that produces the value, and a tool that generated plausible rows would let a team skip the conversation while producing a document that looks like they had it.
Facts
| A failure mode | Attaches to an item revision, a characteristic, or a process step |
| Not a description | The row is attached to the part, not about it |
| On a limit change | Rows referencing that characteristic are flagged for review |
| Ratings | Typed, on your scale; RPN and AIAG-VDA action priority both held |
| Never calculated | Severity · occurrence · detection |
| Evidence beside them | Nonconformance history next to the occurrence rating |
| Control plans | Generated from detection controls, so they cannot drift |
| To the ERP | The critical-characteristic flag — the analysis's operational output |
Frequently asked
What is wrong with an FMEA in a spreadsheet?
It detaches. A spreadsheet row names an item in text, so the connection to the actual part exists only in the reader's head — and when the design changes two years later, nobody opens the file because nothing tells them that row is now affected.
What does linking actually change?
A design change surfaces the FMEA rows it invalidates. When a characteristic's limit moves, the failure modes referencing it are flagged; when a component is substituted, the rows citing its properties appear in the impact analysis rather than waiting to be looked for.
Does Manufacturing PLM suggest severity or occurrence ratings?
No. Severity is a judgement about consequence, occurrence a judgement informed by data that is often absent, and detection a judgement about a control's real rather than intended effectiveness. Software producing those numbers would be producing confidence rather than analysis.
How does it help with the ratings then?
By putting the evidence next to them. A row's occurrence rating sits beside the nonconformance history for that item, so a rating of 2 on a component with eleven nonconformances in eighteen months is visibly questionable during review rather than years afterwards.
Do you support AIAG-VDA action priority or RPN?
Both, with the choice held as tenant configuration alongside the rating scales your industry or customer requires. Neither is calculated into a decision on your behalf — they are recorded, displayed and used to sort work that people then prioritise themselves.
What reaches the shop floor from an FMEA?
The critical and significant characteristic designations, which is what an ERP or MES uses to enforce inspection at receipt or in process. An FMEA identifying a critical characteristic that does not then get inspected has produced a document rather than a control.
Can an agent draft FMEA rows for us?
It is deliberately not offered. Cross-functional review is the part of FMEA that produces the value, and a tool generating plausible rows would let a team skip the conversation while producing an artefact that looks exactly like they had it.