Supplier Change Notification: Re-Check Requirements Fast

The email says the supplier has moved a purchased part to a different manufacturing site. Same part number, same datasheet revision, a new plant. The notification calls it a minor change and asks for acknowledgment within a few weeks.

The part is a connector on a harness that sits inside an enclosure your team verified last quarter. Nobody on the thread can say off the top of their head which requirements that connector touches, which test reports it appears in, or who decided it was acceptable the first time.

This walk-through follows one supplier change notification (a PCN) from inbox to decision. The persona is a supplier quality or manufacturing engineer who receives the notice, plus the engineering lead who signs off on accepting it. The job is narrow: work out what the change could invalidate, re-check only what needs it, and leave a record the next reviewer can trust. The scenario is illustrative, and every detail in it is made up to show the workflow.

The PCN arrives on a part your verified design already depends on

A supplier change notification is a supplier telling you that something about a part you buy has changed, or will. The common categories are a new manufacturing site, a material or process change, a revised datasheet, a changed finish, or an end-of-life notice. The supplier writes it from their side of the fence. They know what they changed. They don't know what your design assumed.

That gap is the whole problem. Your design didn't depend on the part number. It depended on specific properties of the part: a contact resistance that kept a voltage drop inside budget, a plating that survived a salt-fog test, a housing material that held shape at the thermal limit. Those properties were true of the part you tested. A PCN is a claim that the part is still equivalent. Your job is to check that claim against what you relied on.

This is also not an ECO. Nobody on your side changed the design. The change is inbound, and it arrives with a deadline set by someone else's schedule. If you handle it as an email to acknowledge, you accept it by default. If you handle it as a change to a verified design, you ask the right question: what did we depend on, and does that still hold?

The scenario we'll follow: a connector in a sealed enclosure, a new supplier plant, and a PCN that says form, fit and function are unchanged. Take that last phrase as the supplier's position, not as a finding.

Before: rebuilding the dependency trail from email, drawings and memory

Without a connected record, the first hour goes to archaeology. Someone searches the shared drive for the part number and finds a drawing, a datasheet from two revisions ago, and a spreadsheet of approved vendors. Someone else remembers the connector came up in a design review but can't say which one. A third person recalls a vibration test and thinks the harness was on the fixture.

Each fact lives in a different place. The requirement that constrains the connector is in a requirements table. The decision to pick this connector over two others is in a review slide or a chat thread. The test evidence is a PDF attached to a report that references the assembly, not the part. The link between all three exists only in the heads of the people who were there.

That produces two failure modes, and both are expensive. The first is over-reaction: the team can't tell what the change touches, so it re-runs a broad slice of testing to be safe. The second is under-reaction: the notice reads as minor, the owner acknowledges it, and a requirement that quietly depended on the old plant's process goes unchecked until a build or a field return surfaces it.

The quality of your answer is capped by how fast you can reconstruct the dependency trail. When that trail is rebuilt from email and memory, it's rebuilt differently each time, by whoever happens to be available. The PCN deadline then shapes the decision more than the engineering does.

The four steps below replace that rebuild with a trace you can repeat. Tandem is built for this connection: it links design intent, requirements, CAD changes and validation evidence in one system, alongside the CAD and PLM tools you already use.

Step 1: Trace the changed part to the requirements and verification evidence that relied on it

Start from the part, not the notice. Find the connector in the design and ask three questions in order. Which assembly and architecture node is it part of? Which requirements apply to that node or to the connector itself? Which verification evidence was recorded against those requirements?

In Tandem, the part's place in the system architecture, the requirements allocated to it, and the validation evidence stored against those requirements sit in the same graph, so the trace is a traversal rather than a search. Change impact identification surfaces what a change affects, and requirement checks can run against linked CAD. You're reading a connected record, not assembling one.

For our connector, the trace might return a short list like this:

• A requirement on voltage drop across the harness under load.

• A requirement on ingress protection for the sealed enclosure.

• A requirement on survival of a vibration profile.

• A design review where the connector choice was discussed, with the rationale attached.

• Three pieces of verification evidence: a continuity and resistance measurement, an ingress test, and a vibration test.

Look at what the list gives you. It's bounded. Out of every requirement on the program, only a handful touch this part. It's also specific: you now know which test reports to open and which review to reread. If your team already keeps traceability across builds, the same discipline applies, and our guide on keeping requirements straight across EVT, DVT and PVT covers how that record holds up as hardware matures.

Do this trace before you read the supplier's justification. Otherwise the supplier's framing sets your question for you.

Step 2: Decide what must be re-verified and what still holds

Now read the PCN against the trace. For each requirement and its evidence, ask whether the stated change could plausibly move the property that evidence demonstrated. That's an engineering judgment, and it should be made per requirement, not per notice.

Here's how the three connector requirements might sort:

• Voltage drop. The evidence was a contact resistance measurement. A new plant can mean a new plating line or crimp process. If the PCN doesn't address contact resistance, this is a candidate for re-verification on parts from the new site.

• Ingress protection. The seal depends on housing dimensions and material. If the PCN says the tooling and material are unchanged and the site move is the only difference, the earlier ingress evidence may still hold, but you should record why you believe that and ask the supplier for the data that backs the claim.

• Vibration. Retention and mass are unlikely to move on a site transfer alone. This may hold, pending the same confirmation.

Two outcomes are common. Some requirements hold, and you can say so with a stated reason. Others can't be called without more information, and the right move is a question back to the supplier or a targeted check on first-lot parts, not a full re-test.

Keep three bins separate: re-verify, hold with rationale, and hold pending supplier data. Keep them visible. A requirement in the third bin isn't closed, and it shouldn't look closed in your record. If a requirement changes status because the part might no longer meet it, that's a conversation about deviations and waivers, not a quiet acknowledgment.

Tandem stores and connects validation evidence. It doesn't run the test for you, and it doesn't make this call. The engineer does. What the system changes is that the call gets made against the actual requirement and the actual evidence, not against a recollection of them.

Step 3: Record the rationale for accepting or rejecting the change

The decision itself is a small thing. The reasoning behind it is what the next engineer needs, usually six months later, usually under pressure.

Write the rationale where the requirements and evidence live, not in a separate email folder. A useful record answers five things:

• What the supplier said changed, and the date and reference of the notice.

• Which requirements and evidence the part was traced to.

• For each, whether it was re-verified, held, or held pending data, and why.

• What data the supplier provided, if any, and what you asked for and didn't get.

• Who accepted the change and under what conditions, such as a first-article check on the first lot from the new site.

That last item matters more than it looks. Conditional acceptance is common and honest: you accept the change provided the first shipment passes a defined check. If the condition lives only in someone's inbox, it won't survive a handoff. If it lives next to the requirement it protects, it travels with the program.

The same logic makes a design history record useful. The entry is only valuable if it explains the decision, not just logs that one happened. Our guide on keeping the design history file current as the design changes makes the same case for regulated programs, and it applies to an inbound supplier change as much as to an internal one.

Reject is also a valid outcome. If the trace shows a requirement with thin margin and the supplier can't provide data, rejecting the change, requesting last-time-buy quantities, or qualifying a second source are all defensible. The record should show you considered it and why you chose what you chose.

Step 4: Carry the decision into the next build and the next design review

A PCN decision that stops at the acknowledgment has done half its job. The change takes effect on a date, and parts from the new site will show up in a specific build. The people on that build need to know.

Carry three things forward. First, the effective point: which lot, date code or build the changed part first appears in. Second, any conditions from Step 3, such as an incoming inspection on first-lot parts. Third, the open items: requirements still sitting in the hold-pending-data bin.

If your program moves through builds, attach these to the build record so manufacturing sees them without asking. If a lot from the new site goes into a unit that later fails a test, the first question will be whether anything changed. You want the answer to be a link, not a thread.

Then bring it to the next design review. A review is where a held assumption either gets tested or gets forgotten. Reviews in Tandem are held in context, against the requirement, architecture node, CAD change and verification evidence they relate to, so the connector's trace and the supplier decision can be reviewed alongside the design rather than raised as an aside. For programs with a formal board, the same record is what a change control board needs when it asks what the notice touched and who accepted it.

The payoff comes with the second PCN. The next time a notice arrives on any part, the trace and the earlier rationale already exist. You're extending a record, not starting one. In our scenario, a later notice on the same connector family starts from the prior decision, the conditions attached to it and the evidence it rested on, instead of from a blank inbox search.

What Tandem does not do here

A supplier change notification touches several systems, and Tandem is only one layer. Here are the edges.

Tandem is not a CAD tool and not a PLM or PDM replacement. It works alongside the CAD and PLM systems you already use and holds design intent, requirements and evidence rather than geometry or file versions. It doesn't receive or parse your supplier's notice for you, and it isn't a supplier portal.

It has no BOM, supplier or ERP sync. It doesn't know which suppliers sent notices, and it doesn't track approved vendor lists or part lifecycle status. It isn't a quality management system, so corrective actions, supplier audits and nonconformance workflows live elsewhere.

It doesn't author engineering change orders, and it doesn't run tests. It stores and connects validation evidence, but a re-verification still happens on your bench or at your test lab. It doesn't decide whether a change is acceptable. The engineer does, with the trace and evidence in front of them.

What it does is narrower and, for this job, sufficient: it holds the connection between a purchased part, the requirements that depend on it, the evidence that showed those requirements were met, and the reasoning behind each decision. That's the part most teams currently rebuild by hand every time a notice arrives.

Conclusion

Pick one purchased part in your current design, ideally one that has already generated a PCN, and run the four steps backward from it. Trace it to its requirements, list the evidence, and see how long it takes to answer: what did we rely on, and who accepted it?

If the answer takes an afternoon of searching email and drives, that's the cost you pay on every notice. Teams that keep design intent, requirements, CAD changes and validation evidence in one connected record answer in minutes and write the rationale as part of the answer. Book a demo with Tandem and bring a real PCN. Walk the trace on your own part, and see whether the decision you'd make today is one you could defend in the next review.