Why Digital Product Passport should connect existing factory systems instead of becoming another isolated database
Most established textile companies already have several systems containing product information.
ERP may hold item codes, orders and suppliers.
PLM may hold specifications and bills of material.
Quality teams may use separate systems for test results.
Compliance teams may maintain certificates in document folders or specialized platforms.
Sustainability data may sit somewhere else again.
Then Digital Product Passport arrives.
A natural question follows:
Where should all the DPP data live?
The answer is usually not:
“Put everything into the DPP platform manually.”
A more sustainable approach is to understand which existing system is the authoritative source for each type of information and allow the passport to connect those sources around the product.
ERP is usually strong in transactional data
ERP systems are designed to run the business.
They may contain:
product codes
purchase orders
production orders
supplier records
inventory
batches
shipments
customer information
This makes ERP extremely important for DPP.
But ERP may not contain every piece of information a product passport needs.
A system designed for inventory and finance may not be the best place to manage detailed repair guidance or consumer-facing sustainability information.
The objective is therefore not to force the entire passport into ERP.
It is to reuse the reliable information ERP already controls.
PLM or technical systems know the product specification
Product Lifecycle Management systems and technical packs often contain richer product information.
For garments, this may include:
material composition
bill of materials
trim specifications
construction details
colorways
size ranges
approved materials
care information
These records can become valuable DPP inputs.
The challenge is determining which version is final.
Development data can change many times before production.
A passport should use the approved production specification rather than an early development version.
Compliance information may remain separate
Certificates and test reports frequently need their own controls.
A document may have:
issuer
scope
issue date
expiry date
approved facility
related material
related product
Rather than copying every certificate into several systems, the DPP can maintain the relationship between the product and the controlled evidence.
The original evidence can remain in the compliance repository.
The DPP becomes the product-facing layer
A useful way to think about architecture is:
ERP runs transactions.
PLM manages product definition.
Compliance systems manage evidence.
Supplier systems manage upstream information.
The DPP brings the relevant approved information together around the product identity.
This architecture reduces duplicate data entry.
It also reduces the risk of employees manually typing different versions of the same information into several systems.
Under ESPR, Digital Product Passport data is expected to use open, interoperable formats and be transferable without vendor lock-in, which makes integration capability an important design consideration.
Decide the system of record for every field
Factories should create a simple data-source map.
For example:
GTIN — product master
Buyer style — ERP
Fibre composition — approved technical specification
Supplier — sourcing master
Production batch — ERP
Certificate validity — compliance system
Consumer care guidance — approved product-content record
The DPP should consume or reference those approved sources.
This prevents arguments later about which value is correct.
Do not integrate everything on day one
A pilot does not require a large IT project.
Controlled manual upload can be useful while the company is learning.
Once the product dataset becomes stable and volumes increase, automate the repetitive areas.
Integration should solve a proven operational problem.
Not become a goal by itself.
Key Ideas
- Textile companies already hold DPP information across several existing systems.
• ERP is valuable for transactions and product identities but may not hold every passport field.
• PLM and technical systems often contain richer product specifications.
• Compliance systems should remain the controlled source for evidence.
• The DPP can act as the product-facing layer connecting approved data sources.
• Every important field should have a defined system of record.
• Integration should follow stable processes and real volume.
Conclusion
Digital Product Passport should not create another information island.
It should connect the systems the factory already trusts.
At QUIVK, we believe good DPP architecture begins with a simple question:
Where does the correct information already live?
Once that answer is clear, technology can connect the pieces without unnecessary duplication.
