Centric PLM

Before we touch a single flow, we map which fields in Centric PLM are actually load-bearing downstream: style number, colourway, size run, BOM, target cost, approved supplier. Most retailers can name the PLM fields that matter but not which ones ecommerce, ERP and the warehouse each consume, and in what state.

We trace the handoffs as they exist today, usually a mix of exports, manual spreadsheets and point-to-point feeds into the PIM, ERP or storefront, and flag where a style can go live commercially before its costing or compliance data is complete. The commercial outcome on offer is straightforward: fewer SKUs launched with incomplete or wrong cost data, which means cleaner margin reporting from day one rather than a correction cycle three months later.

The question that decides whether this works is not 'what can Centric PLM export' but 'what does Centric PLM get to decide once a style is live'. PLM should own product development attributes: style, colourway, size scale, BOM, tech pack revision. It should not own live sellable status, stock position or final retail price, even though it is often the first system to know a size run has changed. Get this wrong and you get phantom SKUs live on a storefront the warehouse has never received, or a size curve change in PLM that silently breaks an already-live listing.

Ownership map we use on most Centric PLM estates: - Centric PLM: style, colourway, BOM, target cost, tech pack version - ERP: landed cost, GL mapping, approved supplier payment terms - Ecommerce/PIM: live sellable status, retail price, channel-specific content - WMS: physical receipt, bin location, pack configuration

Decide this before any flow gets built, not after the first conflicting update.

Centric PLM was never built to talk natively to a storefront, an ERP and a warehouse system at once, so the honest options are a scatter of point-to-point exports and scripts, or an integration layer that can take a style approval event and fan it out to every system that needs it, each in the shape it expects. Patchworks is the integration layer we use for this: it gives Centric PLM one place to publish an event, rather than a separate script per downstream system, and lets a new channel or warehouse get added without touching the existing Centric PLM connection at all.

That matters most at range expansion, when a retailer adds a marketplace or a third warehouse mid-season and discovers the PLM feed was hardcoded for two destinations, not three. Patchworks makes that an onboarding task, not a rebuild. Specialists reviewing flagged exceptions, supported by AI-assisted delivery rather than an AI-first platform, catch a stalled cost update or an unmapped attribute before it turns into a pricing error, and the running cost stays predictable because you aren't paying developer time for every new connection point.

The failure mode to watch for is quiet: a SKU exists in the ERP and storefront but its cost or size data in Centric PLM has moved on without anyone resyncing it. No ticket gets raised, because nothing visibly breaks until a margin report doesn't add up or a size curve mismatch shows up as a returns spike on one colourway.

What we build is visibility that catches the gap before finance closes the month, not after: a queue health view on cost and SKU update flows, an exception list for styles stuck in 'approved' past a defined window, and a drift check comparing live SKU attributes against the current PLM record season by season. Where this breaks: when teams treat a successful export as proof the data landed correctly downstream, rather than checking what the receiving system actually did with it.

Teams need three things cold: which system is the source of truth for a given field, what an 'approved' state in Centric PLM actually triggers downstream, and who to call when a cost update hasn't landed by the time buying needs it. We write this as a short runbook, not a manual: an escalation owner for stalled SKU creation, an escalation owner for cost mismatches, and a weekly check that buy-ready styles have actually reached the ERP. Most of this training is unlearning the habit of treating a PLM export as finished work.

After go-live we stay on the exception queue, because the first few product cycles after cutover are where mapping gaps show up: a new attribute someone added to the PLM template that nothing downstream expects, a size scale that doesn't map cleanly to the ERP's unit of measure. Peak for a PLM integration isn't a single sales day, it's the pre-season buy window when hundreds of styles move from approved to buy-ready in a short period and every cost mismatch multiplies across a whole range rather than one SKU. We hold tighter escalation through that window and through each seasonal range load, then step back to a lighter managed rhythm once the pattern of failures has settled.