Why is the style-color-size hierarchy the hard part?

Because every system already has one, and they disagree. PLM treats a style-color as a development object with a BOM and a cost; ERP treats it as a family of transactional SKUs; the plan treats it as a merchandising row with a depth and a size curve. None of the three is wrong — they are different projections of the same product — but a number moved between them silently changes meaning unless one shared hierarchy holds the levels together.

How do spreadsheets fracture a data model?

Each workbook redefines the grain. The line plan carries styles by drop, the buy sheet carries style-colors by delivery, the allocation file carries sizes by door — and each file’s definitions live only in its column headers and its author’s head. The model does not disappear; it smears into as many implicit versions as there are files, and those versions reconcile only when a person reconciles them.

Does one data model mean replacing PLM and ERP with one system?

No. PLM stays the system of record for the product and ERP for the transaction. One data model means the planning and workflow layer holds a shared structure — hierarchy, calendar, channels, costs, plans against actuals — that those records feed, so the copies reconcile against something instead of against each other.

How do you tell whether a tool actually has one data model?

Ask what happens underneath: where the size range lives and who may change it, whether a category reforecast cascades to the plans below it, which numbers move when a delivery slips, whether plan and actual share a cell without a hand-built mapping, and what a mid-season recode does to history. A tool with one model answers operationally; a bolt-on integration answers with an export.

// Resources

The apparel data model

An apparel data model is the shared structure a brand’s commercial data lives in — the style, colorway, and size hierarchy; the calendar; channels and locations; costs and prices; and plans held against actuals — with one definition of each object and one stated grain for each number. Every system and every spreadsheet in the stack has a data model. The question is whether the brand has one, or thirty.

This is the essay underneath the rest of this site. The workflow map traces how decisions move between stages; the system of record matrix names which system owns each object. This is the structure both assume: what a shared record actually contains, why the hierarchy is the part that resists, and how to tell when a tool merely claims one.

Short answer

An apparel data model is the shared structure for a brand’s commercial data: the style–colorway–size hierarchy, the season and delivery calendar, channels and locations, costs and prices, and plans held against actuals. The hierarchy is the hard part — the same style-color means different things in PLM, ERP, and the plan — and spreadsheets fracture the model because every file redefines the grain. One shared model is what lets a reforecast cascade instead of being re-keyed.

// What the model contains

Five things, one structure

The contents are not exotic. Any planner could list them from memory, because they are the dimensions every planning conversation already runs on. What makes them a model rather than a vocabulary is that each is defined once, the definitions connect, and every number in the business can say which cell of the structure it belongs to.

Product hierarchy — style, colorway, size

The spine. A style carries the design and the cost; a colorway carries the buy decision; a size carries the commit. Every other object in the model attaches to one of these levels — and most disagreements between systems are disagreements about which level a number lives at.

Calendar — season, drop, delivery, week

When things happen: the season a collection belongs to, the drop it launches in, the delivery that brings goods in, the trading weeks a plan phases across. The calendar is what makes a plan comparable to an actual for the same slice of time.

Channels and locations

Where things are sold and held — DTC, wholesale, marketplace, outlet; warehouses, doors, regions. A number without a channel is ambiguous: full-price DTC sell-through and closeout wholesale revenue must never share a cell.

Costs and prices

What things cost and what they sell for — landed cost by style-colorway, wholesale and retail price by channel, planned and actual markdown. Margin only exists in the model when cost and price attach to the same object at the same level.

Plans and actuals

The same structure, twice. A plan is a decision written into the model — a depth, a phasing, a size curve. An actual is what the season did to it. The two are comparable only because they share the hierarchy, the calendar, and the channels above.

Definition — Apparel data model: An apparel data model is the shared structure a brand’s commercial data lives in — the style, colorway, and size hierarchy; the season and delivery calendar; channels and locations; costs and prices; and plans held against actuals — with one definition of each object and one stated grain for each number, so every team and system reads the same season the same way.; Used by: Merchandising, planning, buying, product development, sourcing, allocation, and technology teams; Related: Merchandise hierarchy, planning grain, system of record, PLM, ERP, apparel operating system

// The hard part

Why the hierarchy is the hard part

Of the five, the hierarchy looks like the easy one — every system in the stack already has styles, colorways, and sizes. That is exactly the trap. Each system holds a different projection of the same product, shaped by the job that system does. None of the projections is wrong. But a number that moves between them silently changes meaning, because the unit it attaches to has changed underneath it.

The same style-color in three systems
System	What a style-color is there	What breaks at the handoff
PLM	A development object — a style with a BOM, a tech pack, and a cost, its colorways added and dropped as development runs.	A colorway killed in development lingers in downstream files, so the plan can carry — and buy — a product that no longer exists.
ERP	A family of transactional SKUs — style-color-size as the unit a PO line, a receipt, and an inventory position attach to.	The plan aggregates what ERP itemizes; joining the two needs a mapping that someone maintains by hand, forever.
The plan	A merchandising row — a style-color with a depth, a size curve, a phasing, and a channel split, at whatever grain that workbook chose.	Each workbook chooses its own grain, so “the same number” from two files disagrees — and both versions are defensible.

PLM

What a style-color is there: A development object — a style with a BOM, a tech pack, and a cost, its colorways added and dropped as development runs.
What breaks at the handoff: A colorway killed in development lingers in downstream files, so the plan can carry — and buy — a product that no longer exists.

ERP

What a style-color is there: A family of transactional SKUs — style-color-size as the unit a PO line, a receipt, and an inventory position attach to.
What breaks at the handoff: The plan aggregates what ERP itemizes; joining the two needs a mapping that someone maintains by hand, forever.

The plan

What a style-color is there: A merchandising row — a style-color with a depth, a size curve, a phasing, and a channel split, at whatever grain that workbook chose.
What breaks at the handoff: Each workbook chooses its own grain, so “the same number” from two files disagrees — and both versions are defensible.

The deeper problem is identity over time. A carryover style re-enters the season under a new code; a colorway is renamed between proto and buy; a factory consolidates two SKUs. A shared hierarchy carries the object through those changes, so its plan, its orders, and its history stay attached to it. Three code lists joined by a mapping file do not — each rename quietly severs a join somewhere downstream. Which level of this hierarchy a given decision belongs at is its own question, taken up in the planning grain; which system is allowed to write each object is the subject of the system of record matrix.

// The fracture

How spreadsheets fracture the model

A spreadsheet does not lack a data model — it has an excellent one, chosen fresh by whoever built the file. That is the problem. The line plan carries styles by drop; the buy sheet carries style-colors by delivery; the allocation file carries sizes by door; the trading file carries categories by week. Each file redefines the grain, and each definition lives only in its column headers and its author’s head. The totals agree at the top for as long as nothing changes, which in apparel is never long.

So the model does not disappear — it smears. The brand ends the season with as many implicit data models as it has workbooks, reconciled by the only integration layer spreadsheets have: a person, cross-checking cells. This is the structural reading of why apparel brands still run on spreadsheets, and the case examined in Apparel OS vs spreadsheets: the flexibility everyone values is precisely the freedom of every file to define the season differently.

// What one model changes

What “one data model” changes operationally

The change is not a cleaner chart. It is a change in the verbs. On a fractured model, a mid-season reforecast is a project: the new category number is agreed in a meeting, then re-keyed into the line plan, the buy sheet, the OTB file, and the allocation model, each by its owner, each on their own timeline, with the versions drifting the whole way. On one model, a reforecast cascades: the levels are arithmetically connected, so moving the category total restates the phasings, receipt flow, and open-to-buy beneath it — and surfaces the style-colors where the new total and the committed orders now conflict, which is the actual decision the team needed to see.

One model does not mean one system. PLM remains the record for the product and ERP for the transaction — the model is the shared structure the planning and workflow layer holds, which those records feed, so every copy has one thing to reconcile against instead of reconciling against each other. That is the layer an apparel operating system owns, and the transfer-by-transfer alternative is what PLM plus spreadsheets looks like without it.

// The evaluation

Five questions that expose a bolt-on

Every vendor claims one data model, and at the demo’s altitude every stack has one — suites assembled by acquisition, planning modules bolted onto BI engines, and integration platforms all show a coherent top level. The difference lives underneath, in what moves without being told. These five questions are the ones a buying team can ask in an hour, each with a concrete answer a vendor cannot stage.

Show me one style-color. Where does its size range live, and who may change it?

In one data model the size range is an attribute of the product record, defined once and inherited everywhere the style-color appears — the buy sheet, the size curve, the allocation. In a bolt-on integration each module keeps its own copy, and the honest answer is a list of places. The follow-up is just as revealing: change the range mid-season, and count how many screens have to be told.

If I reforecast a category, what happens to the plans underneath it?

One model means the levels are arithmetically connected: move the category number and the style-color phasings, receipt flow, and open-to-buy beneath it restate against the new total, with conflicts surfaced rather than silently overwritten. A bolt-on exports the new number into another module — and a person re-keys the layers below it.

When a delivery slips two weeks, which numbers move on their own?

The calendar is part of the model or it is not. If receipt flow, weeks of supply, and channel phasing restate when the delivery date changes, the calendar is a dimension the numbers actually hang on. If the answer is “you would update the plan to reflect that,” the calendar is a label, and the reconciliation is yours.

Can I see plan against actual for the same cell without building the join myself?

Plan and actual are only comparable when they share the hierarchy, the calendar, and the channel dimensions. A tool with one model shows the pair natively at any level. A tool assembled from acquisitions asks you to map the planning structure to the actuals feed — and that mapping file is the spreadsheet problem readmitted through the back door.

What happens when a style-color is recoded mid-season?

Identity is the quiet test. Carryover styles, mid-development renames, and vendor recodes happen every season. In one model the object keeps its identity and its history follows it through the change. Where the integration is a nightly file transfer keyed on the code itself, the recode splits the product in two — plan on one side of the rename, actuals on the other.

// Summary

An apparel data model is the shared structure commercial data lives in: the style–colorway–size hierarchy, the calendar, channels and locations, costs and prices, and plans held against actuals.
The hierarchy is the hard part — PLM, ERP, and the plan each hold a different projection of the same style-color, and a number moved between them silently changes meaning.
Spreadsheets fracture the model because every workbook redefines the grain; the model smears into as many implicit versions as there are files, reconciled only by hand.
One data model changes the verbs: a reforecast cascades through connected levels and surfaces the conflicts, instead of being re-keyed into every file that carries a copy.
One model does not mean one system — PLM and ERP keep their records; it means the planning layer holds the structure the copies reconcile against. Five questions expose a bolt-on: size-range ownership, cascade on reforecast, calendar shifts, plan-vs-actual joins, and mid-season recodes.

// Related resources

See it in RetailNorthstar →

// FAQ

Frequently asked questions

What is an apparel data model?: The shared structure a brand’s commercial data lives in: the style, colorway, and size hierarchy; the season and delivery calendar; channels and locations; costs and prices; and plans held against actuals — with one definition of each object and one stated grain for each number. Every tool in the stack has a data model of its own; the real question is whether the brand has one shared model or many private ones.
Why is the style-color-size hierarchy the hard part?: Because every system already has one, and they disagree. PLM treats a style-color as a development object with a BOM and a cost; ERP treats it as a family of transactional SKUs; the plan treats it as a merchandising row with a depth and a size curve. None of the three is wrong — they are different projections of the same product — but a number moved between them silently changes meaning unless one shared hierarchy holds the levels together.
How do spreadsheets fracture a data model?: Each workbook redefines the grain. The line plan carries styles by drop, the buy sheet carries style-colors by delivery, the allocation file carries sizes by door — and each file’s definitions live only in its column headers and its author’s head. The model does not disappear; it smears into as many implicit versions as there are files, and those versions reconcile only when a person reconciles them.
Does one data model mean replacing PLM and ERP with one system?: No. PLM stays the system of record for the product and ERP for the transaction. One data model means the planning and workflow layer holds a shared structure — hierarchy, calendar, channels, costs, plans against actuals — that those records feed, so the copies reconcile against something instead of against each other.
How do you tell whether a tool actually has one data model?: Ask what happens underneath: where the size range lives and who may change it, whether a category reforecast cascades to the plans below it, which numbers move when a delivery slips, whether plan and actual share a cell without a hand-built mapping, and what a mid-season recode does to history. A tool with one model answers operationally; a bolt-on integration answers with an export.

// See it in RetailNorthstar

See how the Apparel OS comes to life in RetailNorthstar — one connected workflow from line plan to production.

See the Platform →Book a Demo →

See this data model in RetailNorthstar — the platform that holds the hierarchy, the calendar, the channels, and the plan against actuals on one shared product record.