Making the product catalog an operational source of truth

Product data is easy to underestimate because a spreadsheet can hold it. The complexity appears when sales, inventory, purchasing, merchandising, and reporting all need the same product to mean the same thing.

Start with the real hierarchy.

For this operation, a flat SKU list was insufficient. Product identity followed a style, then a colorway, then a sellable size-level SKU. Some attributes belonged to the style, while lifecycle decisions could differ by colorway.

We modeled those ownership rules explicitly instead of copying every attribute onto every SKU. Existing SKU identifiers remained intact so historical sales and reporting relationships did not break.

Migration sources are not always operating sources.

The original sheets remained valuable for controlled import and reference, but automatic replacement would have left the business with two competing masters. After migration, maintenance moved into an authenticated portal with roles, audit history, and explicit imports.

This distinction is important: a source can help create the system without remaining the permanent authority.

The operating model included

• Hierarchical browsing from styles to colorways to SKUs.
• Bulk creation with validation and atomic commit.
• Search, filters, lifecycle changes, and controlled CSV exports.
• Role-based maintenance and an audit trail.
• Compatibility fields for downstream systems during transition.

Governance makes the catalog reusable.

Once product identity was controlled, inventory screens could enrich quantities with consistent style, color, size, and lifecycle information. Sales reporting could use current master data without relying on inconsistent titles captured at the time of sale.

The catalog became infrastructure for future warehouse, planning, and commerce work—not because it held more fields, but because ownership and change were explicit.