Publish a digital catalog

For many companies the catalog is the starting project, because the product data has to be brought together and structured before anything else becomes possible. It is also the lowest-risk way to begin: nobody can place a wrong order against a catalogue, and every later project (shop, portal, spare parts, punchout) is shorter because this one is finished. Skip it and you do the same work later, under time pressure, with a launch date attached.

Why this is harder than it sounds

The hard part is not the import. Imports are an afternoon. The hard part is that the data does not currently exist in the form you need, and getting it there requires decisions that are awkward to reverse.

The awkwardness is specific. Once products carry order history, changing the model is migration rather than editing. Splitting one article into a family with variants, or turning a free-text field into a typed attribute, means reconciling documents that already reference the old structure. Decisions you make in the first fortnight are the ones you live with, which is why modelling comes before loading and why "we will tidy it up later" is the most expensive sentence in this project.

The second obstacle is that "complete" means nothing without naming a channel. The same product can be finished for your web shop and unusable in a customer's procurement system, because that channel demands a unit-of-measure code and a classification the web page never needed. Completeness is a per-channel calculation. Define it once, globally, and you spend the following year arguing about whether the catalogue is done.

Third, much of your data belongs to someone else. Supplier files arrive in whatever structure each supplier prefers, changing without notice, with the attributes you need buried in columns named for their internal logic. Mapping supplier structures onto your model is recurring work. Design it as a repeatable route instead of performing it heroically each time.

And then there is decay. A catalogue is not a project with an end. Without a named owner per attribute group and a routine that runs every week, it is measurably worse a year after launch than on the day it went live, and nobody notices, because the degradation is spread across thousands of products.

The levers

Decide the model before you load anything

What good looks like: you can state, on one page, what an attribute is versus a variant axis, which families exist, which values are typed and which are free text, and how your categories differ from your ERP's article groups. Somebody outside the project can read it and place a new product correctly.

What it depends on: knowing what buyers filter by. Ask sales what customers ask for, look at your own search logs if you have any, and build the model around those answers rather than around the ERP's field list.

1. How product information management works
2. The catalog data model
3. Plan your data model
4. Attributes and attribute groups
5. Families and Variants and family variants
6. Categories
7. Measurements and units · Reference entities

Get the data in

What good looks like: one product created by hand first, to prove the model is workable; then the assortment loaded in bulk from a prepared file; then media attached to products instead of sitting on a shared drive as 4711_neu_final_2.jpg.

What it depends on: the mapping between each source's columns and your model. That mapping is the deliverable. The import run is the trivial part, and a mapping you can rerun turns each supplier update from a project into a task.

1. Create a product
2. Prepare your import file
3. Import products in bulk
4. Edit many products at once
5. Assets and asset families

Define what "complete" means, per channel

What good looks like: each channel has a written requirement. The web needs images and a description; a procurement channel needs units, classification and length limits; a printed sheet needs something else again. The platform calculates completeness against it, so "ready" is a number.

What it depends on: knowing your channels in advance, including the ones you have not built yet. It is much cheaper to add a channel's rules to an existing model than to retrofit data for a channel nobody considered.

1. Channels, locales and completeness
2. Completeness and readiness
3. Data quality in practice
4. Why a product is not showing up

Publish it, and keep it alive

What good looks like: the catalogue is visible where it needs to be, and there is a weekly routine with a person's name against it: new products checked, incomplete products chased, supplier updates run, zero-result searches reviewed.

What it depends on: ownership. Assign attribute groups to the departments that know the answers: technical attributes to product management, logistics data to operations, commercial text to marketing.

1. How storefronts work
2. Create a storefront
3. Search and discovery
4. Edit pages and blocks
5. Languages and markets
6. Notifications

A sensible order

Phase 1: model, then one family, completely. Design the model, then load a single product family by hand and take it all the way to complete for one defined channel. This is small enough to redo when it turns out to be wrong, which it will be the first time. Its value is that it converts a modelling discussion into a concrete artefact people can look at and argue about productively.

Phase 2: bulk-load the assortment, in revenue order. Work down from the families that carry the most revenue. Publish the catalogue as soon as the first group is complete instead of waiting for all of it. A partially published catalogue that is correct is far more useful than a complete one that is still internal. Phase 2 depends on Phase 1's model holding, which is what Phase 1 was for.

Phase 3: the second channel, and the maintenance loop. Add whichever channel comes next (a procurement channel for punchout, a second language, a print or datasheet output) and put the weekly routine in place with named owners. Phase 3 is what stops the catalogue from being the best it will ever be on launch day.

Common mistakes

• Adopting the ERP export as the model. The ERP's structure was designed for invoicing. It will give you a 40-character description and no filterable attributes.
• Letting the attribute list grow unmanaged. Every field needs a purpose and an owner before it exists.
• Defining completeness globally. Without a channel, "complete" is a feeling.
• Leaving media on the shared drive. Images and datasheets that are not attached to products are not part of the catalogue, whatever the folder is called.
• Onboarding every supplier at once. Do one properly, build the reusable mapping, then use it.
• Waiting for perfection before publishing. Publish the complete part. The rest is a visible, prioritised backlog.
• No maintenance routine. A catalogue without one is at its best on the day it launches and declines from there.

How you know it is working

• Products at 100 % completeness for your primary channel, as a count and as a share. This is the headline number, and it only means something once completeness is defined per channel.
• Filterable attributes available to buyers, counted per category. Two filters in a category with 4,000 articles is not a findable catalogue.
• Share of the assortment with at least one image and a datasheet. The cheapest quality proxy there is, and usually the most embarrassing number at the start.
• Zero-result searches, ranked by frequency. Every entry is either a product you do not sell or a modelling gap, and both are worth knowing.
• Attributes with a named owner. Anything without one will be out of date within a year.
• Elapsed time to onboard a new supplier's data. If the second supplier takes as long as the first, the mapping route is not reusable yet.
• Products whose data has not changed in a year, as a share. In a live catalogue this figure stays low; when it climbs, maintenance has stopped.

Related goals

• Launch a B2B shop, the project this one is the foundation of.
• Reach more customers, because a published catalogue is the first source of new demand.
• Consolidate systems, where the catalogue is usually the first domain to consolidate.

What you're building

A product catalog in the platform's PIM that holds every sellable article with typed attributes, families, variants, categories and media, fed from your ERP and your suppliers through repeatable imports, with completeness measured per channel. A public storefront shows the complete part. No prices, no checkout yet. Everything later reads from this one catalog.

flowchart LR
  ERP["Your ERP: article master"]
  SUP["Supplier files: BMEcat, CSV"]
  DAM["Images, datasheets"]
  subgraph IS["Integration Studio"]
    IMP["Import profiles"]
    WF["Workflows"]
  end
  subgraph CS["Commerce Studio"]
    DM["Data model: families, attributes"]
    P["Products"]
    CAT["Categories"]
    AS["Assets"]
    CH["Channels"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront: catalog pages"]
  end
  ERP --> IMP
  SUP --> IMP
  IMP -- "mapped columns" --> P
  DAM --> AS
  AS --> P
  DM --> P
  P --> CAT
  CH -- "completeness per channel" --> P
  P -- "complete products only" --> SF
  WF -- "scheduled supplier updates" --> IMP
  SRCH["Search app (planned)"]:::planned
  P -.-> SRCH
  SRCH -.-> SF
  classDef planned stroke-dasharray: 5 5

What you need

• A one-page data model: attributes versus variant axes, families, typed versus free-text values, categories — Plan your data model
• A list of what buyers filter by, from sales and from search logs — How PIM works
• A written completeness requirement for your first channel — Channels, locales and completeness
• The ERP article export and the first supplier file, with a column mapping you can rerun — Prepare your import file
• Images and datasheets collected and named by article number — Assets and asset families
• A named owner per attribute group — Data quality in practice
• A storefront to publish to, even a plain one — Create a storefront

Build it

1. Write the model on one page and have product management sign it — Plan your data model
2. Create attribute groups and attributes with units in the Cockpit — Attributes
3. Create families and, where combinations are finite, family variants — Families
4. Build the category tree in the buyer's logic — Categories
5. Create the first channel and its completeness requirement — Channels
6. Create one product of the first family by hand and take it to 100 % — Create a product
7. Map the ERP export to the model and import the top-revenue families — Import products in bulk
8. Attach media through asset families — Assets
9. Fix the incomplete products in bulk, family by family — Edit many products at once
10. Publish the complete families on the storefront — Create a storefront
11. Map the first supplier file and schedule the update — Import/export
12. Put the weekly routine in the calendar with names — Data quality in practice
13. Add the second channel's completeness rules when it is decided — Completeness and readiness

Decisions you'll need to make

Related product areas

• Commerce Studio — Products · Product list import · Bulk actions · Families · Family variants · Attributes · Attribute groups · Measurements · Categories · References · Assets · Completeness · Channels
• Experience Studio — Sites · Pages · Languages and markets
• Integration Studio — Import/export · SFTP server · Schedules · Runs