Product Stewardship and Substance Compliance Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does part matching get underscoped so often?

Because on a slide it is a join. Supplier sends a declaration, declaration names a part, system finds the part. In a proof of concept using twenty clean declarations it works, and the project gets funded on that basis.

What breaks it is that a supplier's part string is not your part number. It may be their internal code, the manufacturer part number, a variant with a packaging suffix, an obsolete number superseded twice, or a description with the number embedded in it. Your side is no better: the same physical component sits under an internal number, one or more manufacturer part numbers, and an approved alternate that purchasing qualified last year. Nobody normalised any of it, because inside each system the local identifier was sufficient.

This is specific to substance compliance because the output is a signed statement. A mismatch in a purchasing system produces a late delivery. A mismatch here produces a full material disclosure that says a part is clear when the declaration you matched belongs to a different component.

The fix is to design matching as a component with its own accuracy target and its own confirmation queue. Resolve supplier part strings against your approved vendor list including manufacturer part numbers and known abbreviations, propose a match with a confidence level, and route anything below the threshold to a person. Every extracted value carries a provenance link back to the source page, so an auditor and your own compliance manager can both check it. In our builds, extraction and matching together take handling of a declaration from ten or fifteen minutes to under two, and the traceability is what makes the saving usable rather than merely fast.

What goes wrong with historic declarations and product structures?

Two data problems decide whether the rollup is trustworthy, and both are usually assumed away.

The first is the shared drive. Around a thousand declarations, a third of them more than three years old, some scans of scans, some of your own templates filled in with not applicable across every row. Backfilling all of it sounds like the obvious first step and is often the wrong one, because a declaration whose scope you cannot determine is worse than a known gap: it looks like coverage in a report and is not.

The second is product structure, and it is the one that quietly corrupts arithmetic. Phantom assemblies exist in the bill of material and not in the physical product. Alternates mean the part in the box depends on what purchasing had in stock that week. Process chemicals such as plating, flux, adhesive and marking ink are physically present and frequently absent from the bill of material entirely. Configurable products only resolve their structure at order time. A rollup that treats the engineering structure as the physical truth will be confidently wrong.

The fix on history is to backfill by exposure rather than by volume: your top few hundred purchased parts by spend, plus anything on a product line with active customer requests, and mark everything else as a known gap rather than importing uncertainty. The fix on structure is to encode your own rules explicitly, phantom handling, alternate resolution, process chemical attachment at operation level, and to have the output show which parts contributed, which are evidenced and which are assumed.

Why do enterprise and product lifecycle integrations break after launch?

You need both systems, they answer different questions, and both change without telling you.

The product lifecycle system holds the engineering structure and revision history. The enterprise system holds what was actually purchased against each line. A compliance statement needs both, because the engineering structure tells you what was designed and the purchasing record tells you what is in the box. Integrations here break when an engineering change releases a new revision and the compliance record still points at the previous structure, or when purchasing qualifies an alternate and the alternate has no declaration at all.

The alternate case is the dangerous one, because nothing failed. The part shipped, the customer took delivery, and the statement you issued last quarter no longer describes the product.

What to require: a trigger on new revision release and on new approved alternate, both of which create work rather than passing silently. Structure queries pinned to a named revision so a rollup can be reproduced exactly as it was computed. Integration written against the specific system and version, since a Teamcenter structure query is not a Windchill one and an Arena or home grown structure database is different again. And a reconciliation report that lists parts appearing in purchasing with no corresponding compliance record, reviewed monthly by a named owner rather than emailed to a distribution list.

What happens when list monitoring and statement versioning are left out?

This is the gap that turns a good system into an exposure, because it fails silently and on somebody else's schedule.

The REACH candidate list of substances of very high concern is updated periodically, typically twice a year, and each update can turn a part you have bought for a decade into a reportable article overnight. RoHS exemptions expire on published schedules. Restrictions on other substance groups are moving in several jurisdictions at once. None of that involves any change on your side, which is exactly why it goes unnoticed until a customer asks.

Subscription platforms do monitor the lists, and that is a fair reason to keep one. What they cannot do is tell you which of your open customer commitments are affected, because they do not hold the record of what you told which customer, on what basis, and when.

The fix is to keep every statement you have issued as a versioned object with the data it was computed from, then re evaluate every affected product when a list changes. That produces two work queues: parts needing a fresh declaration, and customers holding a statement that is now stale. The second queue is the one that protects the relationship, because telling a customer before their auditor does is an entirely different conversation from telling them after. Build the versioning into the first release, since statements issued before it exists cannot be reconstructed.

Should you build custom or configure what you already own?

Many manufacturers should subscribe rather than build, and some should do both.

If you have a few hundred purchased parts, one product line and one regulated market, buy. Assent and iPoint will chase your suppliers more effectively than an internal team can, because supplier chasing is a relationship business and they ask on behalf of many customers at once. Sphera operates in the same space. The subscription will cost less than running your own system, and the response rates will be better.

The honest hybrid is the answer more often than either extreme, and it is worth putting to a board explicitly: subscribe for supplier campaigns and list monitoring, and build the part matching, rollup, statement versioning and customer output layer that a subscription cannot fit around your product structures. That combination usually costs less than forcing either approach to do the whole job.

Build the second layer when two or more of these hold. You carry several thousand purchased parts across product lines with different structures. Your rollup depends on one person's workbook and that person has no realistic backup. You have configurable products where the compliance answer depends on the configuration ordered. Your customers each demand a different output format and your team rebuilds packs by hand every quarter. Or you have been asked for full material disclosure rather than a simple compliance statement, which is a far harder data problem than it sounds.

How do hidden costs get into the quote?

These are the lines that move a substance compliance number.

• Number of regulatory regimes. Each carries its own threshold logic, exemption handling and output format, and they do not share work.
• Threshold basis differences. RoHS restrictions apply at homogeneous material level while other obligations use article weight, so a declaration giving a percentage against the whole component is not directly usable. Encoding that correctly is real work.
• Bill of material complexity, especially configurable products and heavy use of alternates, where resolution rules are genuinely hard.
• Product lifecycle integration, which varies enormously between Teamcenter, Windchill, Arena and a home grown structure database.
• Historical backfill, meaning how many years of existing declarations you extract and match rather than starting clean. A separate phase with a separate budget.
• Multi division rollout, where each division numbers parts differently and each insists it is correct.

In Digital Heroes delivery experience, a first release covering declaration intake with extraction and matching, the part level substance data model, bill of material integration and automated rollup with a computed basis runs $60,000 to $140,000 over 12 to 16 weeks. A full platform adding supplier campaign management, list change monitoring with re evaluation, SCIP and conflict minerals outputs, customer specific export templates and a supplier facing portal runs $180,000 to $400,000 over 6 to 12 months.

What separates a build that works from one that fails here?

Four things, and the first is what the system outputs.

The answer is never a single compliant flag. It is a statement with a computed basis: which parts contributed, which are covered by declarations, which are assumed, and what the exposure is if an assumption is wrong. That last column is what turns compliance from a claim someone signs into a risk position management can act on, and it is what lets a compliance manager say no with evidence rather than hedge.

Extraction feeds a confirmation queue, always. Any developer promising fully automatic extraction with no human review on data you legally attest to is selling you a risk rather than a saving. Ask what accuracy they will commit to, how it is measured, and how it improves as corrections are made.

Customer output formats are configuration, not code. Every customer wants their own spreadsheet with their own column names in their own portal. If adding a format requires a developer, your compliance team is still rebuilding packs by hand and the highest return automation in the category has been skipped. Log each submission against the customer and the product so the next request starts from history.

And the evidence is yours, in your accounts, agreed before kickoff. This system underwrites statements you sign, which means the declarations, the extracted values, the provenance links and the issued statement history all have to be exportable in an open format. Holding your own compliance evidence is not a commercial preference here. It is the reason the evidence is worth anything.