# Mapping the apparel data landscape: from PLM to POS
A single black cotton t-shirt, style number WM-2401, exists in six different systems before a customer buys it. In one system it is a "concept sketch," in another a "cost roll-up," in a third a "sellable SKU," and in a fourth a "unit shipped." When those six versions disagree, your assortment planner reorders a color that never sold. This lesson follows WM-2401 across the stack so you know which system owns which truth.
Fashion data lives in a relay race of specialized systems. Each one owns a stage of the garment's life and hands data to the next.
Common systems you will meet in the wild: Centric PLM and PTC FlexPLM for design, SAP and Oracle NetSuite for ERP, Salsify and Akeneo for PIM, Manhattan and Blue Yonder for WMS/OMS, and Shopify or NewStore at retail. No single vendor owns all six well, which is exactly why the data disagrees.
Let's trace the four attributes that matter most: style, size, color, cost, and sell-out.
In PLM, WM-2401 is one style: a men's crew-neck tee. But a style is not sellable. Once you add size (XS to XXL) and color (Black, White, Navy), you get SKUs (Stock Keeping Units), the atomic unit of inventory. One style times 6 sizes times 3 colors equals 18 SKUs.
This is the first place data breaks. PLM thinks in styles. WMS, OMS, and POS think in SKUs. If the size run changes late (design drops XS), the systems downstream may still carry a "phantom" XS SKU that shows stock but can never ship.
Rule of thumb: PLM owns the style definition. ERP owns the SKU master. Everyone downstream should read the SKU master, never invent their own.
Color is where governance goes to die. In PLM, the color is a Pantone reference and a mill dye lot. In PIM, marketing renames it "Midnight" for the website. In POS, the receipt just says "BLK."
Now analytics asks: "How did navy sell?" If PIM calls it "Midnight," ERP calls it "NVY," and POS calls it "410," you cannot join those datasets without a color mapping table. Most retailers maintain one; the ones who don't spend Mondays reconciling spreadsheets.
There are two costs, and confusing them corrupts margin analysis.
PLM cost is a plan. ERP cost is the truth. Any margin report should pull cost from ERP, not PLM. The US International Trade Commission tariff schedule drives a chunk of that landed-cost gap for imported apparel, which is why the two numbers rarely match.
Sell-out (also called sell-through) is the percentage of received units actually sold. Only POS knows it, because only POS records the sale.
Worked example for WM-2401 in Black, size M:
Units received (WMS): 500
Units sold (POS): 340
Sell-through = 340 / 500 = 68%A 68% sell-through eight weeks into a season is healthy for a basic tee. The danger: if OMS shows 340 sold but POS returns data shows 25 came back, your net sell-through is 315 / 500 = 63%. Returns data (usually flowing POS to OMS) is the attribute teams forget to net out.
| Attribute | System of record | Common wrong source |
|-----------|------------------|---------------------|
| Style definition | PLM | ERP guesses |
| SKU master | ERP | Each channel invents its own |
| Color naming | PIM (display), PLM (spec) | POS abbreviations |
| Cost (landed) | ERP | PLM target cost |
| On-hand inventory | WMS | ERP snapshot (lags) |
| Sell-out / returns | POS / OMS | Manual reports |
The single most useful governance move: publish this table internally and name a data owner for each row. That is governance in practice, not theory.
🎬 [VIDEO: "What is Product Information Management (PIM)?" - youtube.com - a clear 6-minute primer on how PIM sits between your ERP and sales channels]
Generic data-quality dimensions (completeness, accuracy, consistency, timeliness) get specific in apparel. Track these:
Active SKUs: 2,400
SKUs missing primary image: 180
Completeness = (2400 - 180) / 2400 = 92.5%At 92.5% you are below a 95% gate: 180 products would show a broken image online. That is a concrete, fixable data-quality defect, not an abstraction.
Knowledge check
1. An assortment planner reorders a color that never sold at retail. Which system's data should have been treated as the authoritative source to prevent this mistake?
2. Why does the apparel data landscape rely on six specialized systems rather than one unified platform?
3. A garment is 'one style' in PLM but becomes many entries in downstream systems. This 'SKU explosion' is best understood as a consequence of what?
4. Select ALL correct answers. Which statements accurately describe how 'ownership of truth' is distributed across the apparel stack?
Select all the correct answers.
5. Select ALL correct answers. Why can the 'same' t-shirt appear inconsistent across systems?
Select all the correct answers.
Governance sounds bureaucratic until WM-2401's navy variant shows 200 units in ERP and 150 in WMS. Which number does the buyer trust to reorder?
Answer: WMS for physical on-hand, ERP for financial valuation. They serve different questions. ERP's number can lag because it updates on a batch cycle (sometimes overnight), while WMS updates in near real time as units move. Neither is "wrong"; they answer different questions at different refresh rates.
Three governance practices that separate mature apparel data teams:
1. A published system-of-record map (the table above), reviewed each season.
2. Master data governance for new styles: a SKU is not "live" until ERP creates it and PIM completes required attributes. This stops phantom SKUs.
3. Reconciliation SLAs: for example, WMS and ERP inventory must reconcile within an agreed tolerance (say 2%) by a set time daily. Set the tolerance to your business; the discipline matters more than the exact number.
Two measurement benchmarks recur across apparel analytics. Treat both as directional, and always compute your own from POS data:
The data lesson: a single headline metric hides the story. Segment sell-through by full-price versus markdown, by color, and by size, all of which require clean joins across the six systems you just mapped.