Composite pattern: a manufacturer replacing spreadsheets with a PIM

Situation: technical product data in a dozen spreadsheets

This is a composite pattern built from several PIMvendors selections, with no single client behind it. It describes a European manufacturer of technical products, sold mainly through wholesalers. The range has many variants, and each product carries dozens of technical attributes.

Product data lived in spreadsheets kept by engineering, marketing and customer service. The ERP held article numbers, prices and logistics data. Wholesalers asked for data classified to ETIM and delivered as BMEcat files, and each request triggered a manual export.

The cases overview lists the other composite patterns. This one is the most common starting point PIMvendors sees.

Complication: no agreed definition of a product

The manufacturer had three versions of each product and no rule for which one was right. Engineering's spreadsheet held the specifications. Marketing's spreadsheet held descriptions and images. Customer service kept a third list with corrections from complaints.

An earlier attempt to buy a PIM had stalled after generic demos. Every vendor looked capable on its own demo data. The team could not compare vendors because it had never written down its own data model.

Wholesaler pressure made the problem urgent. Incomplete ETIM data meant products were listed with missing attributes, or not listed at all.

What the selection did differently

The selection started with the data model and ownership, and only then looked at software. The sequence followed the house order: Data, then Process, then People, then Tooling.

1. The team modelled two representative product families, including variants, units and ETIM classes.
2. Engineering became steward of technical attributes; marketing became steward of descriptions and media; a product data owner arbitrated.
3. The team mapped the product creation process from engineering release to wholesaler export.
4. Requirements were checked against the PIMvendors checklist, with the Data model and quality domain prioritised.
5. Only then did the RFP go out, with scenarios built from the modelled families.

This order is described in designing the product data model before selection.

Which scenarios decided the selection?

Three scenarios separated the shortlist, and all three used the manufacturer's own data.

A fourth scenario covered bulk updates from engineering. Engineering changes many attributes at once after a product revision. Vendors that handled this only through manual screens dropped down the list.

The scenario-based demo guide explains how to write scenarios like these.

Outcome patterns

The scenarios changed the shortlist more than the RFP answers did. Vendors that answered "yes" to ETIM support in writing showed very different levels of support in the demo. Some stored ETIM classes natively. Others needed a custom mapping layer.

The data model work paid off before contract. Gaps in the model surfaced during scenario preparation, when they were cheap to fix. The cheapest licence on the shortlist came with the most integration and mapping effort, which the team priced into its comparison.

Adoption after go-live tracked the ownership agreement. Where stewards were named before selection, the spreadsheets were retired faster.

Where this pattern goes wrong

The pattern fails when the RFP runs ahead of the data model. In engagements where the model was skipped, vendors were scored on their own demo data. The chosen vendor then met the real variant logic during implementation, and the project stretched.

Ownership by IT alone is a second failure point. An IT-led project can select a sound platform, while engineering and marketing keep their spreadsheets because nobody gave them a role. A third risk is treating ETIM as an export task. Classification belongs in the data model, so it should be tested in the data model.

Lessons for manufacturers in a similar position

Define the product before you compare the software. Four lessons recur across the engagements behind this pattern.

• Model two representative product families before writing the RFP, including variants and classification.
• Name stewards per attribute group and one owner who arbitrates.
• Test ETIM and wholesaler exports on your own data, since written RFP answers overstate support.
• Price integration and mapping effort alongside the licence.

Manufacturers with a large supplier base face a different bottleneck, covered in the distributor supplier onboarding pattern. Smaller teams buying a first PIM can compare this pattern with the mid-market first PIM pattern.