Connecting a DPP to Your ERP and PLM

The first instinct on a passport programme is to build a place to put passport data. It is almost always the wrong instinct, because the data already exists and the problem is that nothing can reach it in one place.

Which system owns what

A manufacturer of any size runs several systems that each hold part of a product record, divided along lines that made sense when they were implemented and that no longer map cleanly onto a passport.

The last row causes recurring problems. Manufacturing execution systems know precisely which components went into which serial number, and frequently discard that detail after a few months because nothing downstream needed it. A serialised passport needs exactly that record.

The authority question

Several systems will hold the same attribute with different values, and the mapping exercise is largely about deciding which one wins.

Product weight is the standard illustration. PLM holds the designed weight, ERP holds a shipping weight that includes packaging, and the quality system holds a measured weight from sampling. All three are correct answers to different questions, and a passport attribute asking for product weight needs one of them.

Reference, do not copy

The tempting architecture copies values from source systems into a passport store on a schedule. It works immediately and degrades steadily.

Every copied value is a value that can go stale, and product data changes constantly — a supplier substitution, a revised specification, a corrected test result. A passport built on copies is a snapshot of what was true whenever the last sync ran.

• Resolve at read time where the source system can support the load and the latency.
• Cache with an explicit age where it cannot, and show the age rather than hiding it.
• Version deliberately so a passport read last year can be reconstructed for an audit.
• Never let a copy become the only remaining record, which is how source systems get quietly decommissioned.

The third point deserves emphasis. A passport is a legal assertion at the moment it is read, and a market surveillance question about a product placed on the market two years ago asks what the passport said then, not what it says now.

Where the mapping usually breaks

Three failure modes account for most of the delay on these programmes, and all three are discoverable in the first fortnight if anybody looks.

The first is granularity mismatch. A passport attribute asks per product; the source holds it per material group. No integration resolves that — somebody has to produce the finer data.

The second is documents instead of values. Quality systems store a test report as a PDF, and an attribute asking for a measured value cannot read it. The number exists and is not addressable.

The third is identifier mismatch. PLM keys on an internal part number, ERP on a material number, the supplier on their own catalogue number, and nothing holds a reliable mapping between them. This is the most common cause of a programme that appears to be nearly finished for several months.

A sequence that works

The ordering matters more than the tooling, because each step reveals whether the next one is feasible.

Most of the effort lands in steps three and four, and most programmes discover this after building an integration layer for attributes the source cannot actually supply at the required granularity.

The supplier boundary is a different problem

Everything above concerns data a manufacturer already holds. A significant share of passport attributes concerns things only a supplier knows, and no amount of internal integration produces them.

Substance concentrations at homogeneous material level, upstream carbon footprints, recycled content shares and origin claims all originate outside the organisation. They arrive through a supplier process rather than a system integration, and they arrive slowly.

This distinction is worth drawing early, because the two workstreams run at different speeds and have different owners. Internal mapping is an engineering exercise measured in weeks. Supplier data collection is a commercial exercise measured in contract cycles, and it should start first precisely because it finishes last.

The systems question that follows is where supplier-supplied values land once they arrive. Filing them in a portal that nothing else reads recreates the addressability problem one step further out, so supplier data needs the same authority decision as any internal attribute.

What to build first

Start with one product family rather than one system. A single family carried end to end reveals every mapping problem in miniature, at a scale where fixing them is still cheap.

Starting with one system instead — integrating all of PLM, say — produces a large amount of connected data that cannot yet populate a single complete passport, which is a demoralising place to arrive after a quarter of work.

Choose the family deliberately rather than taking the easiest one. A product with a complex bill of materials, several suppliers and at least one substance declaration will expose problems that a simple product hides, and those problems are the ones that decide the shape of the eventual architecture.

Resist the temptation to fix the data quality issues you find by hand in order to demonstrate progress. A passport populated through manual correction proves only that the data can be produced manually, which was never in doubt and does not scale to a portfolio.

The output of a first family should be two things: a working passport, and a written list of every place the data was not where it should have been. The second is more valuable than the first, because it is the actual scope of the programme.