Most ERP projects within fashion & lifestyle brands are signed off and scoped by finance, or digital. That person runs the weekly meetings, holds the budget and signs off the design. The people who will live in the system every day usually see it for the first time in UAT, six to nine months later.
By then their input arrives as a change request. It gets priced and argued about against a plan everyone has already agreed to, and some of it gets dropped because go-live is now too close to peak.
So this one is written for the person doing the early research. You are probably in finance or operations or digital, and you are probably the one who has to explain the cost of this later. Here is who needs to be involved, and when.
Merchandising decides more of the build than anyone expects
Merchandising is the domain most ERP programmes never really cover, which is why it is worth naming first.
Why merchandising gets left out
Nobody sets out to exclude them. Their involvement never gets made mandatory, by the brand or by the systems integrator, so it comes down to one short high-level session and then nothing genuinely useful again until UAT. The people gathering requirements do not really understand merchandising, and the merchandisers have not been shown what an ERP can and cannot do for them, so everyone leaves that session thinking it went fine.
A merchandising calendar also has no quiet period, so the hours that ought to go into the project go into trading, planning and managing the year instead. Go-live tends to get planned around the finance calendar or peak trading, which puts UAT and training exactly where ranges are being signed off and orders placed with suppliers.
Some of it is not an ERP problem at all. A good deal of the upstream work belongs in a modern PLM, and vendors and SIs tend not to raise it, so the brand finds out late and the gap limits how useful the ERP ever becomes.
Product data is where the damage compounds
Product means different things in different brands. Buying, product development, or both, plus whoever raises the purchase order and manages intake with the supplier. Wherever it sits, it is the function that creates the record every other system depends on.
A field added to satisfy one report can break something two integrations away, and the break usually shows up somewhere else entirely, weeks later, as a data problem nobody can trace back.
Finance treats multi-entity as a discovery rather than a decision
Multi-entity and multi-currency are design decisions. They get found halfway through instead, when a brand opens a US entity or starts selling in a second currency. Reconciliation is the same shape of problem. Designing it in costs a conversation in week two. Bolting it on costs a bad month-end, and then several more.
Operations knows how the 3PL actually behaves
Purchase orders and commitment visibility belong in one place, and operations is the function that can tell you what one place means in your business. Inbound and allocation have to match how your 3PL behaves in practice rather than how the contract describes it. The people dealing with that gap daily are the only ones who can describe it.
Three more, and they have the same problem
Digital and ecommerce, wholesale and retail each get their own piece. Wholesale runs on its own clock and does not survive being modelled as DTC with a different customer record. Retail does not inherit the DTC playbook.
“When you do an ERP, you have to take people on the journey. That time never got carved out of their day jobs, so it didn’t really happen.”
The common factor is timing. Each of these teams gets brought in after the decisions that affect them most have already been made. Bring them in at the start and the specification gets better, because they are reacting to something real rather than describing a system they have never used.
What Atelier is for
Atelier is what we already know about how each of these teams works, written down before a project starts. Every department is covered, including the ones a programme usually gets to last.
That means the standards and the questions arrive on day one rather than at the end. A merchandiser does not have to invent their requirements from a blank page in the middle of a trading peak, because the process is already described and their job is to correct it rather than author it. The same holds for product data and for intake.
It also means the upstream gaps get named early. If something belongs in a PLM and not the ERP, we would rather say so in week two than have it arrive as a change request during UAT.
None of it is complicated. It has just never been handed to anyone at the start of a project.