Implementing a planning system? Fix your attributes first

Six weeks into a merchandise financial planning rollout, the project team hits the same wall every time: the system is configured, the hierarchies are mapped, the workflows are approved, and the first pilot report comes back wrong. Not wrong because the software is broken. Wrong because "fabric: cotton" and "fabric: 100% Cotton" and "fabric: ctn" are three different values sitting in the same column, and the planning tool has no way to know they're the same thing. Multiply that across fifty attributes and twenty thousand SKUs and you get a go-live that everyone quietly distrusts.

This is the part vendors don't put in the demo. Assortment planning, merchandise financial planning, and allocation tools — whether it's a platform like Toolio built for merchandising teams, an enterprise suite like Blue Yonder or o9, a flexible modeling layer like Anaplan, or a forecasting engine like Impact Analytics — all share one assumption: that the item attributes feeding them are complete, standardized, and correct. None of them are built to fix your data. They're built to plan on top of it.

The planning system didn't fail. The inputs did.

A forecast, an assortment plan, or an allocation rule is fundamentally a rollup. You're aggregating sales history and inventory positions along dimensions: category, silhouette, color family, price tier, fabric, fit, channel. Every one of those dimensions is a product attribute. If the attribute is missing, that SKU falls out of the rollup silently. If the attribute is inconsistent, similar items get split into different buckets and look like distinct, thinner trends instead of one strong one. If the attribute is wrong, the model learns a false pattern and repeats it at scale.

None of this shows up as an error message. It shows up as a planner squinting at a report that doesn't match their gut, then spending the first two quarters after go-live rebuilding trust in the numbers instead of using them. Clean, well-structured master data is what powers forecasting, financial planning, pricing, allocation, and replenishment — but that data rarely exists in the shape a new planning system needs on day one. It exists scattered across a legacy ERP's free-text fields, a PLM tech pack, a handful of spreadsheets a merchandiser maintains locally, and whatever the vendor's product page says.

Industry guidance on ERP-adjacent implementations is blunt about where this actually breaks. One implementation framework puts it plainly: "most cutover-weekend failures trace to data, not to software," and warns that "migrating dirty data is fast; living with dirty data in the production system is slow and expensive." The same guide recommends a master-data quality assessment in the first six weeks of any rollout, treating data readiness as a parallel workstream from day one rather than a task squeezed into the week before cutover. Planning system implementations run on the same physics. The item master is arguably a harder problem than the transactional data ERPs worry about, because attributes come from more sources and get typed in more inconsistently.

What "ready" actually means

"Clean data" is too vague to plan against. Teams need three concrete, testable conditions before a planning system implementation should treat the item master as done:

Fill rate is the easiest to measure and the one teams check first. It's also the least sufficient. A field can be 100% filled and still useless if half the values are free-text guesses typed in during a rushed initial load, or copy-pasted from a supplier spec sheet years ago and never revisited. Validated correctness is the condition most rollouts skip entirely, because checking a value against its source (a spec sheet, a product photo, a lab test result) at SKU scale has historically required manual review — error rates in manual data entry run 1-4%, higher for complex specification fields, which is exactly the kind of noise a planning model can't tell apart from real signal.

Sequencing enrichment alongside the rollout

The instinct in most projects is to configure the planning tool first and treat attribute cleanup as a parallel IT ticket that can slip. That ordering is backwards. Attribute work has to lead, or at minimum run in lockstep, because the planning team's early configuration decisions (which attributes define a "style," which roll up into a "class," which drive allocation logic) are themselves decisions about which attributes need to be trustworthy first.

A workable sequence looks like this. Before kickoff, inventory which attributes the planning model will actually use as dimensions — not every field in the PIM, just the ones that feed forecasts, rollups, and allocation rules. During solution design, run fill and standardization checks against that specific list, and start validating the values that carry the most weight in the model (the attributes that split SKUs into different demand buckets) rather than trying to boil the ocean. By the time the planning system moves into configuration and testing, the attribute layer underneath it should already be stable enough that pilot reports reflect real merchandising patterns, not data artifacts.

This doesn't require ripping out the PIM, ERP, or PLM system already in place, and it doesn't touch the planning vendor's roadmap. It's additive work against whatever catalog of record already exists, pulling attribute values from the tech packs, BOMs, product imagery, and review text that already sit around the business, standardizing them against a controlled vocabulary, and flagging conflicts between sources instead of silently picking one. That's the layer Anglera sits in: not a replacement for the PIM or the planning tool, but the enrichment step that makes sure both are working from the same, correct set of numbers. A planning system is only as good as the attributes it aggregates. Fix those first, and the go-live report is one planners can actually act on.