One brand we spoke to recently was running its product data across seventeen separate spreadsheets. Each file had a different owner and its own version of the truth. The critical path sat in one, the bill of materials in another, and sizing in a third that only one person could open without breaking the formulas. Nobody designed it that way. It built up over about three years, one urgent export at a time.
Ask anyone there and they’ll tell you the spreadsheets are the problem. We’d want to know what the spreadsheets are hiding before anyone replaces them.
This one is for whoever owns product data without it being in their job title. That’s often the head of ecommerce or operations, and sometimes product or merchandising. You’re probably being asked to choose a PLM or a new ERP module this year, and you’ll probably be the one asked later why it didn’t fix things.
Every team already has its own definition
Merchandising has one definition of a confirmed product and finance has another. The warehouse usually has the most reliable version, because it gets checked against physical stock every day.
Spreadsheets keep those definitions apart, so for a while nobody notices the gap. A shared system puts them side by side from the first week. That’s why so many rollouts feel worse in month one. The mess was already there, and the new system shows it to people who couldn’t see it before.
We saw the same thing at another fashion brand. The PO master lived in one tool and the bill of materials in another, with a third added later to cover whatever didn’t fit either. There was no shared validation between them. The people closest to the product were each working from a different definition of it, and each was right about their own part of the business.
Ask when the critical path was last written down
A quick test is to ask when the critical path was last documented in full, start to finish, somewhere everyone can see.
If the answer is a long pause or a date from two years ago, you’re looking at an ownership problem dressed up as a data problem. Nobody was made responsible for the thing everyone downstream depends on, so nobody built it until the pain got bad enough to force it.
Agree what a product is before you buy software to hold it
None of this is an argument against spreadsheets, or against buying a PLM or a new ERP module. Sometimes buying one is the right call, and the risk sits in the order you do things in.
If the system arrives before the definitions and owners are agreed, you’ll spend the next eighteen months configuring software around a disagreement it can’t resolve. What was missing was one governed version of what a product is, and a clear rule on who is allowed to change it.
Do that first, even roughly on a whiteboard, before the vendor demos start. Otherwise the new system tends to become spreadsheet eighteen, with a nicer login screen and a bigger invoice.
If you’re the one being asked to pick the system, take this into the room before the demos. Find out who owns the critical path and who is allowed to change a product after the PO goes out. If nobody can answer, that’s the first thing to fix, and it costs a lot less than the software.