The enrichment cleared the backlog. The process work is why it did not come back.
inRecipe enriched technical, physical and customs attributes while Data Design established ownership and a standardised item process across seven teams.
attributes per item, across a backlog of thousands
lower cost per record than manual research, by the customer’s estimate
on one shared item process
Situation
Product data was spread across several systems, ownership was unclear, and data quality was poor enough to cause errors and manual work. Incomplete product structures blurred the financial picture behind decisions. A backlog of thousands of items had built up across seven teams, waiting for procurement, attribute resolution and customs classification.
- Product data spread across several systems, ownership unclear
- Thousands of items waiting across seven teams
- Enrichment as a clean-up project on the side
- One end-to-end ownership model, with roles and responsibilities
- The backlog cleared, over 10 attributes per item
- Enrichment inside the new item process
What was done
Current state mapped through stakeholder interviews.
An end-to-end ownership model built, with roles and responsibilities.
Data flows modelled from product development through to reporting.
BOM and item processes standardised.
A roadmap drawn for rollout.
The backlog broken with inRecipe enrichment, filling technical, physical and customs data as part of the new item process, not as a separate clean-up project.
Result
- One end-to-end ownership model.
- A standardised BOM and item process, shared by seven teams.
- A roadmap for continuous development.
- The backlog cleared: over 10 attributes per item, at about 75 % lower cost per record than manual research.
- The enriched records imported into PDM in one batch.
Plausible, well-formatted and unverifiable.
Values with no source
Our first enrichment runs let the system fill fields from what it already knew and from search results, and some of those values were wrong in the most expensive way: plausible, well-formatted and unverifiable. That failure is why every value now carries its document and page, and why a value without one is not written in.
Rule nowEvery value carries its document and page.
The neighbouring row
A second class of error survived even that rule for a while: a manufacturer’s family datasheet lists several variants on one page, and a reading could pick the neighbouring row with a correct page citation; catching it needed a person to name the variant before the values were read, which is now how family documents are handled.
Rule nowA person names the variant before the values are read.
Gaps that were not ours to close
And some gaps were never ours to close: configured, build-to-order items with no single orderable part number, suppliers recorded as manufacturers, and fields such as country of origin that the maker’s documents simply do not state. Those stayed empty, marked “searched, not found”, and went back to the customer as decisions rather than as data.
Rule nowMarked “searched, not found” and returned as a decision.
One item from the backlog
Illustrative, not the customer’s data: an item as it waited in the backlog, and as it went into the new item process.
| Row | Item | Description | Mfr. part number | Bore | Net weight | Customs code |
|---|---|---|---|---|---|---|
| Backlog state | 7720-0148 | BRG 6204 2RS C3 PUMP UNIT | — | — | 0,00 | — |
| Enriched | 7720-0148 | BRG 6204 2RS C3 PUMP UNIT | 6204-2RS/C3 p. 18 | 20 mm p. 18 | 0.11 kg p. 18 | 8482 10 90 proposed |
A backlog waiting across teams?
- 1Send 100 to 200 items from the backlog as they are today.
- 2Within days you see what can be filled from the makers’ documents, what is refused and why, and which fields need an owner.
- 3One hour to walk it through together.
Your ERP, PDM or PIM stays where it is. A file export is enough to start.
Customs classification →